Different airspace users will have different mission needs, requiring flight plan formats able to reflect them and also to leverage the flexibility of the drone operations. Besides, future smart services addressed to optimize or support the design of the missions could take as input details that can make a difference in their results. Do you want to help us to identify all these parameters? You can also suggest a candidate format por a future U-plan standard that would boost the compatibility between the services offered by the U-space Service Providers.
On January 7th 2024, during the first AI4HyDrop Workshop, we invited the participants to contribute with their suggestions for U-plan data and format. We will listen to your feedback along the whole project (around the end on 2025), to reflect your ideas in a final report.
Note that here we want to focus in the flight plan sent by the operators to U-space, not in any dataset that could be shared between services.
To introduce the motivation of the survey, it was explained the case of the project Labyrinth. During it, operators were allowed to submit plans where trajectories would be described as a sequence of points or an area to scan, with the possibility to add some area to avoid.
However, during the validations, the final users reported different needs that had to be reflected also in the flight plan, like the possibility to define geo-cages, to fly at a certain altitude, or to define segregated volumes in the origin or destination for the fixed wings to execute their climb/descend manoeuvres. There were also technical limitations and the desire to specify preferences to be allowed if possible.
In Labyrinth, it was selected JSON as the format for the messages to communicate with the U-space.
Same as in the project DACUS, Labyrinth selected the GeoJSON standard to represent the flight plans. It allows to describe the trajectories as a sequence of points and areas or volumes.
In GeoJSON, a large number or elements can be added to the coordinates, which allows to specify information and constraints associated to the waypoints.
However, inspired by proposals that suggest high level flight plan specifications, we could consider the possibility of using plans with the capability to reflect complex parts like conditions or loops.
The article in the slide was suggesting a high-level format that would be translated into a list of waypoints to be uploaded to the drone. In our case, a similar high-level specification could be sent to the Operation Plan Preparation/Optimisation service, which would convert it to a more low-level format to be processed by the Flight Authorization service. In the event that the Operation Plan Preparation/Optimisation service is not available, the option to directly send a simpler format should be possible.
All this is just a suggestion and we want to hear your feelings about the existence of both formats and what details or semantics would you need to be reflected on them.
Add your contributions to the following board (choose Guest, write any random name, and then you will be able to add sticky notes)
or just write to us: MiguelAngel.FasMillan@dlr.de
Some needs are only identified when final users create their missions for real flights, that is why your feedback is important us!