Skip to content
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

Open
ktian94 opened this issue Sep 6, 2018 · 3 comments
Open

Implementation for non-conforming at 0.5Hz position reporting rate #111

ktian94 opened this issue Sep 6, 2018 · 3 comments

Comments

@ktian94
Copy link

ktian94 commented Sep 6, 2018

Should there be a standard implementation check for this or will it be left up to the USS?

From Slack:

what is the expected check for seeing if an operator is reporting position at 0.5Hz? For example, should we simply check if the operator has sent a position in the last 1s + buffer? Should we look at the trailing N position updates and see if the average Hz is < 1Hz - buffer?

This is in response to the following ReportingRicky requirement:

USS recognizes that its operation begins submitting position data at 0.5Hz which is non-conforming with its requirements to fly BVLOS.  This will last for 20 seconds.  Note that the operation stays geographically and temporally conforming during this time.
@nasajoey
Copy link
Member

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?

@esparano
Copy link

esparano commented Oct 31, 2018

@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...

@nasajoey
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants