You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
for (received_at, notification) insub_notif_interactions:
231
+
forsubinnotification.subscriptions:
232
+
if (
233
+
sub.subscription_id==self._subscription_id
234
+
andnotification.service_area.owner
235
+
==test_flight.uss_participant_id
236
+
):
237
+
notification_reception_times.append(received_at)
238
+
239
+
iflen(notification_reception_times) ==0:
240
+
check.record_failed(
241
+
summary="No notification received",
242
+
details=f"No notification received from {test_flight.uss_participant_id} for subscription {self._subscription_id} about flight {test_flight.test_id} that happened within the subscription's boundaries.",
243
+
)
244
+
continue
245
+
246
+
# The performance requirements define 95th and 99th percentiles for the SP to respect,
247
+
# which we can't strictly check with one (or very few) samples.
248
+
# Furthermore, we use the time of injection as the 'starting point', which is necessarily before the SP
249
+
# actually becomes aware of the subscription (when the ISA is created at the DSS)
250
+
# the p95 to respect is 1 second, the p99 is 3 seconds.
251
+
# As an approximation, we check that the single sample (or the average of the few) is below the p99.
details=f"Notification(s) received {avg_latency} after the flight ended, which is more than the allowed 99th percentile of {self._rid_version.dp_data_resp_percentile99_s} seconds.",
Copy file name to clipboardExpand all lines: monitoring/uss_qualifier/scenarios/astm/netrid/v19/nominal_behavior.md
+41Lines changed: 41 additions & 0 deletions
Original file line number
Diff line number
Diff line change
@@ -18,6 +18,10 @@ A set of [`NetRIDServiceProviders`](../../../../resources/netrid/service_provide
18
18
19
19
A set of [`NetRIDObserversResource`](../../../../resources/netrid/observers.py) to be tested via checking their observations of the NetRID system and comparing the observations against expectations. An observer generally represents a "Display Application", in ASTM F3411 terminology. This scenario requires at least one observer.
20
20
21
+
### mock_uss
22
+
23
+
(Optional) MockUSSResource for testing notification delivery. If left unspecified, the scenario will not run any notification-related checks.
24
+
21
25
### evaluation_configuration
22
26
23
27
This [`EvaluationConfigurationResource`](../../../../resources/netrid/evaluation.py) defines how to gauge success when observing the injected flights.
@@ -26,8 +30,22 @@ This [`EvaluationConfigurationResource`](../../../../resources/netrid/evaluation
26
30
27
31
If specified, uss_qualifier will act as a Display Provider and check a DSS instance from this [`DSSInstanceResource`](../../../../resources/astm/f3411/dss.py) for appropriate identification service areas and then query the corresponding USSs with flights using the same session.
28
32
33
+
## Setup test case
34
+
35
+
### [Clean workspace test step](./dss/test_steps/clean_workspace.md)
36
+
29
37
## Nominal flight test case
30
38
39
+
### Mock USS Subscription test step
40
+
41
+
Before injecting the test flights, a subscription is created on the DSS for the configured mock USS to allow it
42
+
to validate that Servie Providers under test correctly send out notifications.
43
+
44
+
#### ⚠️ Subscription creation succeeds check
45
+
46
+
As per **[astm.f3411.v19.DSS0030,c](../../../../requirements/astm/f3411/v19.md)**, the DSS API must allow callers to create a subscription with either onr or both of the
47
+
start and end time missing, provided all the required parameters are valid.
48
+
31
49
### Injection test step
32
50
33
51
In this step, uss_qualifier injects a single nominal flight into each SP under test, usually with a start time in the future. Each SP is expected to queue the provided telemetry and later simulate that telemetry coming from an aircraft at the designated timestamps.
@@ -120,10 +138,33 @@ Per **[interuss.automated_testing.rid.observation.UniqueFlights](../../../../req
120
138
121
139
Per **[interuss.automated_testing.rid.observation.ObservationSuccess](../../../../requirements/interuss/automated_testing/rid/observation.md)**, the call for flight details is expected to succeed since a valid ID was provided by uss_qualifier.
122
140
141
+
### Validate Mock USS received notification test step
142
+
143
+
This test step verifies that the mock_uss for which a subscription was registered before flight injection properly received a notification from each Service Provider
144
+
at which a flight was injected.
145
+
146
+
#### ⚠️ Service Provider issued a notification check
147
+
148
+
This check validates that each Service Provider at which a test flight was injected properly notified the mock_uss.
149
+
150
+
If this is not the case, the respective Service Provider fails to meet **[astm.f3411.v19.NET0740](../../../../requirements/astm/f3411/v19.md)**.
151
+
152
+
#### ⚠️ Service Provider notification was received within delay check
153
+
154
+
This check validates that the notification from each Service Provider was received by the mock_uss within the specified delay.
155
+
156
+
**[astm.f3411.v19.NET0740](../../../../requirements/astm/f3411/v19.md)** states that a Service Provider must notify the owner of a subscription within `NetDpDataResponse95thPercentile` (1 second) second 95% of the time and `NetDpDataResponse99thPercentile` (3 seconds) 99% of the time as soon as the SP becomes aware of the subscription.
157
+
158
+
This check will be failed if it takes longer than 3 seconds between the injection of the flight and the notification being received by the mock_uss.
159
+
123
160
## Cleanup
124
161
125
162
The cleanup phase of this test scenario attempts to remove injected data from all SPs.
0 commit comments