Paola Tomasello - Liabilities of Remotely Piloted Aircraft Systems (RPAS): the ALIAS project approach
•Download as PPTX, PDF•
1 like•894 views
Drones (namely RPAS) have been chosen as case study to test the Legal Case, the novel methodology, developed by the ALIAS Project, to proactively address liability of new aviation technologies. This presentation shows how the methodology has been applied to address liability issues of drones. It presents the step 1 of the Legal Case process, dealing with the human factors analysis of drones. This intends to define task allocation between the remote pilot and the drone in order to derive task responsibilities of all actors involved in drones operations.
Recommended
Recommended
More Related Content
Similar to Paola Tomasello - Liabilities of Remotely Piloted Aircraft Systems (RPAS): the ALIAS project approach
Similar to Paola Tomasello - Liabilities of Remotely Piloted Aircraft Systems (RPAS): the ALIAS project approach (20)
More from ALIAS Network
More from ALIAS Network (20)
Recently uploaded
Recently uploaded (20)
Paola Tomasello - Liabilities of Remotely Piloted Aircraft Systems (RPAS): the ALIAS project approach
- 2. Liabilities of RPAS: the ALIAS approach
- 3. RPAS chosen as case study to test the Legal Case
- 4. Why RPAS ►Level of maturity is high ►Likelihood of integration in European total system may depend on liability issues ►Legal uncertainties may hinder the development of the European market for RPAS ►Instance of advanced automation with a significant impact on ATM system ►Complex multi-level regulatory framework
- 5. Legal Case validation activities ►Experts interviews ►2 test applications, respectively on and (new generation Airborne Collision Avoidance System). Activities: apply the Legal Case collect feedback consolidate the methodology
- 6. Involvement of aviation stakeholders ►Interviewees ►User group members ►Focal point expert of the selected technology supports the team in setting up the user group mediates the cooperation btw the ALIAS team and the user group supports the application of the methodology validates the quality of the results produced
- 7. RPAS stakeholders involved in the Legal Case validation ►Representative from industry as interviewee (S. Turco) ►Regulator representative as Focal point (F. Tomasello) ►Representatives for insurance (Benito Pagnanelli), pilots (Stefano Prola) and the RPAS Operators (Francesco Grimaccia) as User group members
- 8. Test application of the Legal Case on RPAS
- 10. Addressing RPAS level of automation with the Level Of Automation Taxonomy (LOAT) 1. Supports conceptualisation 2. Connects the Legal Case with human-factor research 3. Helps identifying task responsibilities (Responsibility- LOAT) LOAT use in the Legal Case:
- 11. A INFORMATION ACQUISITION B INFORMATION ANALYSIS C DECISION AND ACTION SELECTION D ACTION IMPLEMENTATION Artefact Supported Action Implementation D1 Step by step Action Support D2 Low Level Support of Action Sequence Execut. D3 High Level Support of Action Sequence Execut. D4 Medium Level Automat. of Action Seq. Execut. D6 Low Level Automation of Action Sequence Exec D5 Full Automation of Action Sequence Exec D8 High Level Automation of Action Seq. Execut. D7 Artefact Supported Decision Making C1 Automated Decision Support C2 Rigid Automated Decision Support C3 Low Level Automatic Decision Making C4 Full Automatic Decision Making C6 High Level Automatic Decision Making C5 Artefact Supported Information Analysis B1 Low Level Automation Support of Info Analysis B2 Med. Level Automation Support of Info Analysis B3 High Level Automation Support of Info Analysis B4 Full Automation Support of Info Analysis B5 Artefact Supported Information Acquisition A1 Low Level Automation Support of Info Acquisition A2 Med. Level Automation Support of Info Acquisition A3 High Level Automation Support of Info Acquisition A4 Full Automation Support of Info Acquisition A5 VLOS/E-VLOS Manual Information Acquisition A0 Working-memory based Information Analysis B0 Human Decision Making C0 Manual Action and Control D0
- 12. A INFORMATION ACQUISITION B INFORMATION ANALYSIS C DECISION AND ACTION SELECTION D ACTION IMPLEMENTATION Step by step Action Support D2Low Level Automation Support of Info Analysis B2Med. Level Automation Support of Info Acquisition A3 Human Decision Making C0 A3 based on user’s settings the system filters and/or highlights the most relevant information B2 Based on user’s request, the system analyses different information items C0 The human generates decision options and decides all actions to be performed. D2 each action is based on human initiative VLOS/E-VLOS
- 13. A INFORMATION ACQUISITION B INFORMATION ANALYSIS C DECISION AND ACTION SELECTION D ACTION IMPLEMENTATION Artefact Supported Action Implementation D1 Step by step Action Support D2 Low Level Support of Action Sequence Execut. D3 High Level Support of Action Sequence Execut. D4 Medium Level Automat. of Action Seq. Execut. D6 Low Level Automation of Action Sequence Exec D5 Full Automation of Action Sequence Exec D8 High Level Automation of Action Seq. Execut. D7 Artefact Supported Decision Making C1 Automated Decision Support C2 Rigid Automated Decision Support C3 Low Level Automatic Decision Making C4 Full Automatic Decision Making C6 High Level Automatic Decision Making C5 Artefact Supported Information Analysis B1 Low Level Automation Support of Info Analysis B2 Med. Level Automation Support of Info Analysis B3 High Level Automation Support of Info Analysis B4 Full Automation Support of Info Analysis B5 Artefact Supported Information Acquisition A1 Low Level Automation Support of Info Acquisition A2 Med. Level Automation Support of Info Acquisition A3 High Level Automation Support of Info Acquisition A4 Full Automation Support of Info Acquisition A5 VLOS/E-VLOS Manual Information Acquisition A0 Working-memory based Information Analysis B0 Human Decision Making C0 Manual Action and Control D0
- 14. A INFORMATION ACQUISITION B INFORMATION ANALYSIS C DECISION AND ACTION SELECTION D ACTION IMPLEMENTATION Artefact Supported Action Implementation D1 Step by step Action Support D2 Low Level Support of Action Sequence Execut. D3 High Level Support of Action Sequence Execut. D4 Medium Level Automat. of Action Seq. Execut. D6 Low Level Automation of Action Sequence Exec D5 Full Automation of Action Sequence Exec D8 High Level Automation of Action Seq. Execut. D7 Artefact Supported Decision Making C1 Automated Decision Support C2 Rigid Automated Decision Support C3 Low Level Automatic Decision Making C4 Full Automatic Decision Making C6 High Level Automatic Decision Making C5 Artefact Supported Information Analysis B1 Low Level Automation Support of Info Analysis B2 Med. Level Automation Support of Info Analysis B3 High Level Automation Support of Info Analysis B4 Full Automation Support of Info Analysis B5 Artefact Supported Information Acquisition A1 Low Level Automation Support of Info Acquisition A2 Med. Level Automation Support of Info Acquisition A3 High Level Automation Support of Info Acquisition A4 Full Automation Support of Info Acquisition A5 B-VLOS operations Manual Information Acquisition A0 Working-memory based Information Analysis B0 Human Decision Making C0 Manual Action and Control D0
- 15. A INFORMATION ACQUISITION B INFORMATION ANALYSIS C DECISION AND ACTION SELECTION D ACTION IMPLEMENTATION Medium Level Automat. of Action Seq. Execut. D6Low Level Automatic Decision Making C4Full Automation Support of Info Analysis B5Full Automation Support of Info Acquisition A5 A5 based on parameters defined at design level the system filters and/or highlights the most relevant information B5 Based on parameters defined at design level, the system analyses different information items and triggers alerts C4 The systems generates decision options and decides all actions to be performed. Human is informed D6 each action is based on system’s initiative. Human can interrupt. B-VLOS
- 16. 10 RPAS hypothetical accident scenarios TITLE CLASSIFICATION DAMAGE AREA USAGE third parties RPAS operator's employees things outdoor - non populated area outdoor - populated area area indoor - populated area not malicious malicious Light RPAS falls on a car and causes collision of cars (without injuries to passengers) X X X Theft of RPAS during flight and its use for malicious purposes X X X
Editor's Notes
- Let’s now focus on ALIAS approach on the liability of RPAS RPAS was chosen as one case study in the framework of the validation activities of the Legal Case methodology
- RPAS was chosen as one case study in the framework of the validation activities of the Legal Case methodology
- For both technologies, several legal issues have surfaced. With respect to ACAS X, the display of non-certified ADS-B data is emerging as a controversial issue, in particular with respect to ensuing liability. Another example is the ACAS Xp version, which is expected to have low unit profitability. The current liability allocation and legal risk in this case threatens to undermine the business case for manufacturers. RPAS present a different case, as manufacturing of RPAS is already advanced and the business case for manufacturers is strong. However, regulators are struggling with the task of integrating RPAS into the aviation system; only possibility here is to address the liability allocation to be undertaken in regulations. Remotely Piloted Aircraft Systems (RPAS) were chosen to test the Legal Case methodology because of their growing importance in civil aviation and increasing relevance for the ATM community. Furthermore, RPAS today are in a peculiar situations. On the one hand they are technically operational, especially in military domain or in civil applications which use RPAS at very low altitudes. However, its operational concept is currently in evolution, since the European ATM community is intensively debating on feasibility and affordability of integrating RPAS in civil non-segregated airspace. Several initiatives have already been launched by European Commission, SJU, EUROCONTROL, EASA and other entities to discuss the topic. On the other hand (and especially from the legal point of view) they still hangs in the balance: regulators—from ICAO and EASA to European Commission—are still working on full integration of RPAS in the civil aviation system and the legal framework is not yet defined and coherent. This is why RPAS technology is an important testbed for our methodology. As liability and insurance are most important issues not only for the safety of the technology but also for its commercial deployment, the Legal Case test application on RPAS can provide an important contribution to address these problems and suggest a way to deal with them.
- The validation plan proposed was based on two different validation activities, namely test applications and interviews with stakeholders. Stakeholder interviews were introduced in order to enlarge the amount and the quality of feedback received with the test applications. While the test applications were used to perform concrete iterative step-by-step applications of the methodology, the experts interviews were used to produce hypotheses and gather more general feedback on the quality of the Legal Case, especially with respect to its suitability to the ATM domain and to the quality of the results that it could provide. Although the test applications present the advantage of producing a set of concrete and documented results, they are at the same time constrained by the technology selected and by limited number and specific competences of the stakeholders involved in the test. This limit may bias the results achieved and question their validity, completeness and generalizability. The use of a focal point in the test application (supporting in the selection of a good range of experts with strong expertise) and the addition of interviews enlarges the group and decouples the results from specific technologies, thus allowing to collect additional and more general feedback, that can in turn confirm, extend or question the results already achieved with the test applications (also because of the different competences or domains that could be covered by the stakeholders involved in the interviews). Two main outcomes were expected from each test application of the Legal Case, namely the Report of the test application and the Legal Case Report. The Report of the test applications presented the results of the test applications in terms of validation of the Legal Case. In particular, to provide evidence that the Legal Case has been validated against the criteria of usability, stakeholders’ acceptability and domain suitability. This evidence also includes recommendations for improvement. Results will feed the final consolidation of the methodology together with the results obtained through the expert interviews. The Legal Case Report presented the results of the test applications in terms of legal assessment of the technology under analysis. This means that it will contain the results of the legal risk management process respectively on ACAS X and RPAS. It will be produced by filling in the Legal Case Report template (see ALIAS deliverable D4.2 the Legal Case – final [1]). Such outcome will work both as test for the validation of the quality of the results provided by the tool and as proper legal assessment of the concerned technology.
- Two User Groups were set up, respectively for the test application on ACAS X and for the test application on RPAS. Each User Group involved the main stakeholders affected by the development of the technology under analysis, such as ATCOs, pilots, industries, regulators, insurance, ANSPs, etc. The focal point worked as reliable base for the users’ recruitment. Using a focal point both as subject matter expert and as a stable and reliable support for the Project ensures effective and fit-for purpose selection of the main stakeholders. The focal points were given a special role in the framework of the test applications, as they acted both as technical expert (supporting the whole test application process) and as mediator in the cooperation between the ALIAS Consortium and the User Group. His involvement included the following tasks: attend the initial preparatory meeting provide relevant documents on the technology under analysis support the Project in the definition of the user group participate in the execution of the test application review the results and support the elicitation of lessons learnt and recommendations
- Simona Turco was selected because of her large experience with RPAS. In Italy IDS is at the same time an RPAS manufacturer, operator and remote pilot. She was interviewed mainly as manufacturer, due to the limited involvement of manufacturers in the two test applications. But her wide and multi-faced knowledge of the sector made the interview particularly interesting and worth to be done. A User Group was set up and consisted of a focal point being regulator representative (Filippo Tomasello, formerly from EASA), who led the production of the Annex I (regulatory aspects) in the “Roadmap for the integration of civil Remotely-Piloted Aircraft Systems into the European Aviation System” representatives for insurance (Benito Pagnanelli), pilots (Stefano Prola) and the RPAS Operators (Francesco Grimaccia). The actors were chosen so as to represent the main stakeholders involved in the RPAS. We could not involve an RPAS manufacturer, due to time constraints. However, the manufacturer’s perspective is at least partially covered by the focal point and the operators. The focal point was chosen because of his expertise with RPAS in EASA, as a member of the UVS International (which works on promoting international cooperation and coordination on remotely piloted systems), and in other roles directly and indirectly related to this technology. The focal point also helped to set up the rest of the User Group providing us with the required competences. As the key stakeholders in the RPAS are RPAS operators—a completely new actor in the aviation—the RPAS User Group included three RPAS operators so as to ensure the presence of at least one of these operators during every meeting of the RPAS User Group.
- Step 1 is meant to provide an understanding of the ATM concept, focusing on: the scope of the technology its use in the operational context its impacts on allocation of tasks, roles, and responsibilities its possible failures
- During this step we collected the background information on RPAS, on technical, operational, legal and insurance topics. We prepared a preliminary draft of the supporting Table 1 and then discussed it with the User Group which helped us to fill in the gaps and expand some of the issues where specialised knowledge not publicly available, as is the case of RPAS insurance problems or the suggestion to focus on the RPAS which fly below 150 meters and fall under the categories of VLOS, E-VLOS and B-BVLOS. Operational concept results RPAS was identified as a subcategory of the UAS (Unmanned Aircraft System) family, covering all those UAS with limited capabilities of flying autonomously, that are supposed to be governed by a human operator (usually known as remote pilot) from a remote position (Remote Pilot Station (RPS)) and in constant control of the aircraft. The flying element, called Remotely Piloted Aircraft (RPA) has been considered by ICAO as an aircraft. Therefore, such systems have to comply with the Rules of the Air as stated by ICAO (Amendment 43) as any other aircraft. This position is shared by EASA and therefore general rules on airworthiness and operations also apply to the RPAS, the RPS, the C2 (Command and Control) link and any other necessary element. Technological enablers of RPAS are mainly two, that is, the aforementioned Command and Control link (C2 link) and Detect and Avoid (DAA). As concerns the actors, besides the main ones—such as RPAS operator, remote pilot and RPAS manufacturer—there are also different service providers involved in the deployment of RPAS in civil aviation domain, such as aviation authorities, ANSPs and remote pilot training organizations . The operational concept, although admitting different possibilities of classification, distinguishes two kinds of RPAS operations: Very low level operations, carried out below 150 meters above ground level, including visual line of sight (VLOS), extended visual line of sight (E-VLOS) and beyond visual line of sight (B-VLOS) operations, and Operations above the 150 meters, including radio line of sight (R-LOS) and beyond radio line of sight (B-RLOS) operations. The Legal Case test application was based on the first category, mainly E-VLOS RPAS, which are most popular today. Nevertheless the E-VLOS and B-VLOS were also taken into account in some scenarios (as we will see in the following steps). As already anticipated in the previous sections of this report, the legal framework of RPAS is not yet clear either on the national level or on the international one. Some EU countries have emanated regulations, guidelines and communications, while EASA has issued a basic regulation 216/2008, and ICAO has updated the annexes of Chicago Convention. Discussions and public consultations are taking place, aiming at building a common international framework. The list of insurance issues to be addressed is long since RPAS raise not only third party liability issues, but also issues related to hull insurance, product liability, cargo insurance, and subrogation, issues related to different insurance regimes in different EU countries, etc. Liability problems are also numerous: they also concern jurisdiction and applicable law, state liability, liability of intergovernmental and EU agencies, illegal use of personal data and privacy infringements, etc However in RPAS test application we primarily focused on the third party liability insurance.
- It supports conceptualisation. The LOAT expresses varying levels of interaction between humans and the technology in question. In the first instance, it is used to better understand technology. It provides an accurate account of human-machine interaction and serves as a tool for refining the concept of automation. By conceptualizing automation on the basis of the human factor, it generates awareness of human-machine interaction. It connects the Legal Case with human-factor research, embedding it into that research. In addition to providing a better conceptual analysis of human factors, this approach links the terminology of the Legal Case to the framework of research projects based on the human factor. It makes it possible to stick to a standard vocabulary throughout the project. Although the arguments related to the human factor in the following steps of the Legal Case are examined from a broad automation perspective, they will be expressed through the terminology of the LOAT table. This terminology also forms an argumentation map, making it easier to identify relevant arguments from a human-factor perspective. R-LOAT complements the information included in LOAT by associating each slot in the LOAT table, i.e., each level of automation of a cognitive function, with the corresponding task-responsibilities of the actors involved. By task-responsibility we mean a duty pertaining to the correct performance of a certain task or role. In R-LOAT we specify task-responsibilities pertaining to the following roles: technology users, developers, and managers. It is important that task-responsibilities be identified in the Legal Case, since their violation may lead to the liability of the user or manager involved, as well as of his employer (see ALIAS Deliverable D1.3, Section 3.3.1). In R-LOAT, we also specify the task-responsibilities of the system, namely, the requirements the system should comply with. These, too, are important, since a failure to meet them may make the system’s producers or maintainers liable. By showing the duties associated with each task and level of automation, it facilitates the work of determining whether a person may have been negligent in performing the duties and role assigned to him in the system. In conclusion, the R-LOAT table offers a systematic approach on which to match the degree of automation to different responsibilities of users of automated systems at different levels (e.g., air traffic controller at the tower, pilots, etc.), as well as to the responsibilities of other actors involved (managers, producers, and maintainers). The main uses of the R-LOAT table in the Legal Case are as follows: Support in developing hypotheses of failures and resulting liabilities. R-LOAT supports the legal analyst in understanding what kinds of dynamics in the human-machine interaction led to what kind of failure. By showing the tasks assigned to each person involved in technology’s functioning, the R-LOAT table may suggest what kind of failure took place. For example, by indicating that the user should have understood what the system was telling him, it points to a possible active human error in understanding, whereas by showing that the manager should have provided training, it points to a possible latent organizational condition consisting in inadequate training [39]. Support in legal analysis. R-LOAT supports the legal analyst in understanding what kinds of liability may arise in connection with a given failure. By showing the duties associated with each task and level of automation, it facilitates the work of determining whether a person may have been negligent in performing the duties and role assigned
- A3 The system supports the human in acquiring information on the process s/he is following. It helps the human in integrating data coming from different sources and in filtering and/or highlighting the most relevant information items, based on user’s settings. System should have: supported information acquisition; helped the human to integrate data; helped the human to filter information items; helped the human to highlight the most relevant information items. Users should have: acquired sufficient information and filtered out irrelevant information supported by digital tools; monitored the performance of the supporting system; defined settings for integrating, filtering and/or highlighting of information; been instructed on how to use the system (including the ability to recognize the anomalies). B2 Based on user’s request, the system helps the human in comparing, combining and analysing different information items regarding the status of the process being followed. System should have: supported information analysis upon users’ request. Users should have: compared, combined and analysed different information items and understood the status of the process, supported by digital tools; requested the help of the system when needed; taken duly into account the system’s outcomes; monitored the performance of the supporting system; detected failures of the tools. C0 The human generates decision options, selects the appropriate ones and decides all actions to be performed. Users should have: generated a large enough set of decision options; selected the appropriate ones; decided those to be performed. D2 The system assists the operator in performing actions by executing part of the action and/or by providing guidance for its execution. However, each action is executed based on human initiative and the human keeps full control of its execution. System should have: assisted the operator by executing part of the action; and/or assisted the operator by providing guidance for its execution. Users should have: correctly and in due time executed all action; controlled the execution; assessed the outcome; monitored the performance of the supporting system; detected failures of the tools
- A3 The system supports the human in acquiring information on the process s/he is following. It helps the human in integrating data coming from different sources and in filtering and/or highlighting the most relevant information items, based on user’s settings. System should have: supported information acquisition; helped the human to integrate data; helped the human to filter information items; helped the human to highlight the most relevant information items. Users should have: acquired sufficient information and filtered out irrelevant information supported by digital tools; monitored the performance of the supporting system; defined settings for integrating, filtering and/or highlighting of information; been instructed on how to use the system (including the ability to recognize the anomalies). B2 Based on user’s request, the system helps the human in comparing, combining and analysing different information items regarding the status of the process being followed. System should have: supported information analysis upon users’ request. Users should have: compared, combined and analysed different information items and understood the status of the process, supported by digital tools; requested the help of the system when needed; taken duly into account the system’s outcomes; monitored the performance of the supporting system; detected failures of the tools. C0 The human generates decision options, selects the appropriate ones and decides all actions to be performed. Users should have: generated a large enough set of decision options; selected the appropriate ones; decided those to be performed. D2 The system assists the operator in performing actions by executing part of the action and/or by providing guidance for its execution. However, each action is executed based on human initiative and the human keeps full control of its execution. System should have: assisted the operator by executing part of the action; and/or assisted the operator by providing guidance for its execution. Users should have: correctly and in due time executed all action; controlled the execution; assessed the outcome; monitored the performance of the supporting system; detected failures of the tools
- A3 The system supports the human in acquiring information on the process s/he is following. It helps the human in integrating data coming from different sources and in filtering and/or highlighting the most relevant information items, based on user’s settings. System should have: supported information acquisition; helped the human to integrate data; helped the human to filter information items; helped the human to highlight the most relevant information items. Users should have: acquired sufficient information and filtered out irrelevant information supported by digital tools; monitored the performance of the supporting system; defined settings for integrating, filtering and/or highlighting of information; been instructed on how to use the system (including the ability to recognize the anomalies). B2 Based on user’s request, the system helps the human in comparing, combining and analysing different information items regarding the status of the process being followed. System should have: supported information analysis upon users’ request. Users should have: compared, combined and analysed different information items and understood the status of the process, supported by digital tools; requested the help of the system when needed; taken duly into account the system’s outcomes; monitored the performance of the supporting system; detected failures of the tools. C0 The human generates decision options, selects the appropriate ones and decides all actions to be performed. Users should have: generated a large enough set of decision options; selected the appropriate ones; decided those to be performed. D2 The system assists the operator in performing actions by executing part of the action and/or by providing guidance for its execution. However, each action is executed based on human initiative and the human keeps full control of its execution. System should have: assisted the operator by executing part of the action; and/or assisted the operator by providing guidance for its execution. Users should have: correctly and in due time executed all action; controlled the execution; assessed the outcome; monitored the performance of the supporting system; detected failures of the tools
- A5 The system supports the human in acquiring information on the process s/he is following. The system integrates data coming from different sources and filters and/or highlights the information items which are considered relevant for the user. The criteria for integrating, filtering and highlighting the relevant info are predefined at design level and not visible to the user System should have: supported information acquisition; had predefined criteria from integrating, filtering and highlighting information; helped the human to integrate data; helped the human to filter information items; helped the human to highlight the most relevant information items. Users should have: acquired sufficient information; filtered out irrelevant information, supported by digital tools; monitored the performance of the supporting system; been instructed on how to use the system (including the ability to recognize the anomalies). B5 The system performs comparisons and analyses of data available on the status of the process being followed based on parameters defined at design level. The system triggers visual and/or aural alerts if the analysis produces results requiring attention by the user. System should have: had the parameters for data comparison and analysis predefined; compared and analyzed the data; alerted human if the results of analysis require his attention. Users should have: compared, combined and analysed different information items and understood the status of the process, supported by digital tools; requested the help of the system when needed; taken duly into account the system’s outcomes; monitored the performance of the supporting system; detected failures of the tools; reacted to the alerts of the system. C4 The system generates options and decides autonomously on the actions to be performed. The human is informed of its decision. System should have: proposed decision alternatives; (only if asked by human) generated new decision alternatives. Users should have: selected possible option, either by himself or from machine processes; decided those to be performed; monitored the performance of the supporting system; detected failures of the tools. D6 The system initiates and executes automatically a sequence of actions. The human can monitor all the sequence and can interrupt it during its execution. System should have: started and executed automatically a sequence o actions; been possible to be interrupted or its actions to be modified by the human. Users should have: monitored the performance of the supporting system; acquired sufficient info and detected failures of the tools.
- A5 The system supports the human in acquiring information on the process s/he is following. The system integrates data coming from different sources and filters and/or highlights the information items which are considered relevant for the user. The criteria for integrating, filtering and highlighting the relevant info are predefined at design level and not visible to the user System should have: supported information acquisition; had predefined criteria from integrating, filtering and highlighting information; helped the human to integrate data; helped the human to filter information items; helped the human to highlight the most relevant information items. Users should have: acquired sufficient information; filtered out irrelevant information, supported by digital tools; monitored the performance of the supporting system; been instructed on how to use the system (including the ability to recognize the anomalies). B5 The system performs comparisons and analyses of data available on the status of the process being followed based on parameters defined at design level. The system triggers visual and/or aural alerts if the analysis produces results requiring attention by the user. System should have: had the parameters for data comparison and analysis predefined; compared and analyzed the data; alerted human if the results of analysis require his attention. Users should have: compared, combined and analysed different information items and understood the status of the process, supported by digital tools; requested the help of the system when needed; taken duly into account the system’s outcomes; monitored the performance of the supporting system; detected failures of the tools; reacted to the alerts of the system. C4 The system generates options and decides autonomously on the actions to be performed. The human is informed of its decision. System should have: proposed decision alternatives; (only if asked by human) generated new decision alternatives. Users should have: selected possible option, either by himself or from machine processes; decided those to be performed; monitored the performance of the supporting system; detected failures of the tools. D6 The system initiates and executes automatically a sequence of actions. The human can monitor all the sequence and can interrupt it during its execution. System should have: started and executed automatically a sequence o actions; been possible to be interrupted or its actions to be modified by the human. Users should have: monitored the performance of the supporting system; acquired sufficient info and detected failures of the tools.
- 10 hypothetical scenarios of possible RPAS incidents or accidents. Scenarios are listed in a table including information on: the description of the event and possible failures which could cause it (both latent and active); the rationale for choice; the classification of each scenario. The classification is carried out on the basis of three criteria, as follows: 1. the kind of damage produced by the drone (broken down into: damage to third parties; damage to RPAS operator's employees; damage to things) 2. the kind of area in which the drone is performing its mission (broken down into: outdoor non populated area; outdoor populated area; indoor populated area) 3. the kind of drone usage by the remote pilot (broken down into: not mailcious; malicious) Such classification enables clustering scenarios according to a single criterion, let's say n.1, kind of damage (for example, "damage to things"). In this way, all the scenarios describing a drone accident which caused damage to things are considered as options (micro-scenarios) in the framework of a single macro-scenario, which is featured by the fact that the RPAS damages things (and not people). The same applies if another criterion is selected for classification. Such classification is the starting point to structure the legal analysis. Sce_1 The light RPAS is engaged in a surveillance mission for the control of the territory, as foreseen in its operations manual. It flyes in VLOsS. In particular, it is scanning a portion of territory subject to landslides. It flies in e-VLOS. At a certain moment, the crew loses the control of the RPAS, which continues flying and goes out of visual line of sight. The RPAS falls down, hitting a car which is driving around the area. Due to the bump, the car hits another car driving around. Sce_2 same scenario as Sce_1 (mission in line with operations manual), with the only difference that the RPAS falls on the remote pilot/observer, causing serious injuries to him/her. Sce_3 The RPAS is flying in VLOS to get photographs. At a certain moment, a hacker jams the light RPAS communication links thus disconnecting it from the pilot, and spoofs it with wrong GPS coordinates making the RPAS “think” that it is just above the landing place and has to land. The RPAS is stolen and consequently the operator discovers that it was used illegally to film inside military zone.