-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implementation for non-conforming at 0.5Hz position reporting rate #111
Comments
Perhaps something like: An Operation is NONCONFORMING if the number of positions reported in the last minute are not within 10% of the number or required positions to be reported in that minute. So, if 1Hz is the "rule", then 60+/-6 positions are required within the previous minute for that Operation to stay in the ACCEPTED state. Thoughts? |
@nasajoey More of a theoretical/businessy question: How does NASA determine what is part of the USS-NASA contract versus what is part of the Operator-USS contract? And what parts of the Operator-USS contract does NASA have control over? Is this requirement stepping on the freedom a USS has to interface with an Operator? Or is there any room for USSs to develop "smarter" algorithms for determining whether an operator is conforming? For example, based on the geometries of the operation volumes (and conformance volumes, which are up to the USS anyway), the position, direction, and frequency of position updates, etc. Maybe the operator is in the center of an enormous conformance volume and based on the vehicle's performance characteristics, the USS can still confidently say to NASA that the operator is conforming without necessarily needing 1Hz updates at all times... |
I think the counter argument or major use case is public safety or security. There is a requirement (maybe written down, maybe not at this point), that the ANSP know where each BVLOS operation is within some timeframe and with some level of confidence or within some uncertainty bound. The easiest way to meet that requirement right now is to have the operator providing regular position updates. So while there may be "smart" ways to know that an operation is conforming with its volumes, it may not be complying with the requirement to "be known" within some time frame or uncertainty bounds without receiving those position reports. Now, as requirements get solidified, if it turns out the ANSP would only want to know within 300 ft and within 1 minute of a request from that ANSP, then we may be able to revisit the requirement to receive positions at this rate. Note the other requirement (that again may or may not be written as of today) is that other operations know where other cooperating BVLOS UTM operations are. The position reports satisfy this requirement as well. Didn't think this response through completely, but hopefully gives some insight on the issue. I'm sure if I re-wrote this tomorrow it would be a little different. |
Should there be a standard implementation check for this or will it be left up to the USS?
From Slack:
This is in response to the following ReportingRicky requirement:
The text was updated successfully, but these errors were encountered: