Solutions - Group 4 - 2018/2019, Semester B, Quartile 3

From Control Systems Technology Group
Revision as of 13:42, 14 February 2019 by S.l.derks@student.tue.nl (talk | contribs) (→‎Requirements: Add reference)
Jump to navigation Jump to search

<link rel="shortcut icon" href="https://www.tue.nl/favicon-64.ico" type="image/x-icon"> <link rel=http://cstwiki.wtb.tue.nl/index.php?title=PRE2018_3_Group4&action=edit"stylesheet" type="text/css" href="theme.css">

Solutions

In this section, we consider the requirements of solutions for the problem proposed in the specific problem description, all possible solutions, and both the advantages and disadvantages of each solution.

Categories

When considering the state of the art research presented in the relevant Section, we can distinguish multiple categories in which the presented solutions might fall. In this Section, we further elaborate on these different categories, and as such provide a better overview and allow for more a more specific formulation of requirements.

Categories
Preventative solutions
This category encompasses all solutions that serve to prevent the problem from occurring. More specifically, entries of this category focus on keeping UAVs away from airspace belonging to airports. An example might include the geofencing system that was described previously, and will be elaborated on further in the following sections.
Corrective solutions
Solutions from this category focus on solving the problem of UAV presence in the airspace over airports, specifically when said UAV is already present in that airspace. These solutions attempt to do so with minimal damage to the parties involved, an example might consist of a procedure where the control of the drone is overridden, either automatically or by a human, before the drone is removed from the airspace by landing or flight and after which control could be passed back to the pilot.
Destructive solutions
These solutions have the same area of focus as the previous category of corrective solutions, namely the minimizing of further risk to air traffic above airports after a UAV has entered the airspace. The main difference is that, while corrective solutions attempt to do so in a non-destructive way, this limitation does not apply to destructive solutions. Sub-systems of a UAV or the UAV as a whole may be destroyed or permanently disabled. A coarse example consists of taking down unwanted UAVs with firearms, causing damage to the UAV and rendering it unable to continue operations.


Requirements

A solution to the specific problem described will have to adhere to requirements. These requirements are not simply capabilities the solution has to provide in the form of functional requirements, but they should also cover constraints posed on the solution. The constraints can be on the design of the solution in order to meet specified levels of quality, on the environment and technology of the system, and on the project plan and development methods.

While providing these requirements, we need to make sure they are atomic. Furthermore, they need to be clearly identified, sufficiently precise and unambiguous, sufficiently verifiable, and prioritised. We use the MoSCoW model for the prioritisation of the requirements. This model considers must have, should have, could have, and won't have, which indicate the priority of a requirement.

Furthermore, these requirements might serve as a basic framework for further development of solutions to similar problems, thereby widening the scope to other problem spaces involving UAVs as well.

The functional requirements (capabilities) of the solution are as follows:

  • The solution should be able to take down any type of drone effectively.
  • The solution should not endanger any humans with any of its actions.

Possible solutions

  • Describe all possible solutions possible within the next 20 years or so.

Advantages and disadvantages

  • Advantages and disadvantages based on the requirements of a solution (feasibility of actually making it and jurisdiction).



Back to the root page.