Skip to content

Commit

Permalink
[uss_qualifer] Scenario documentation with 1 testcase for testing SCD…
Browse files Browse the repository at this point in the history
…0080 (#485)

* Scenario documentation for testing SCD0080 req

* Fixing the path req documentation file

* Fixing doc paths

* Fixing doc path

* Fix path

* Update monitoring/uss_qualifier/scenarios/astm/utm/subscription_notifications/receive_notifications_for_awareness/receive_notifications_for_awareness.md

Co-authored-by: Mickaël Misbach <[email protected]>

* Adding more description and diagram to documenation, renaming intents

* Fixing a description as per review comment

* Changed the scenario to use flight2 in non-conforming state as per PR review

* New PR for receive_notifications with 1 testcase

* Fix the diagram

* Update monitoring/uss_qualifier/scenarios/astm/utm/subscription_notifications/receive_notifications_for_awareness/receive_notifications_for_awareness.md

Co-authored-by: Mickaël Misbach <[email protected]>

* Update monitoring/uss_qualifier/scenarios/astm/utm/subscription_notifications/test_steps/validate_notification_received.md

Co-authored-by: Mickaël Misbach <[email protected]>

* Update monitoring/uss_qualifier/scenarios/astm/utm/subscription_notifications/test_steps/validate_notification_received.md

Co-authored-by: Mickaël Misbach <[email protected]>

* Fix per review comments

* Update monitoring/uss_qualifier/scenarios/astm/utm/subscription_notifications/receive_notifications_for_awareness/receive_notifications_for_awareness.md

Co-authored-by: Mickaël Misbach <[email protected]>

* Update monitoring/uss_qualifier/scenarios/astm/utm/subscription_notifications/receive_notifications_for_awareness/receive_notifications_for_awareness.md

Co-authored-by: Mickaël Misbach <[email protected]>

* Fix per review comments

* Fix format

* Update monitoring/uss_qualifier/scenarios/astm/utm/subscription_notifications/test_steps/validate_notification_received.md

Co-authored-by: Mickaël Misbach <[email protected]>

* Update monitoring/uss_qualifier/scenarios/astm/utm/subscription_notifications/test_steps/validate_notification_received.md

Co-authored-by: Mickaël Misbach <[email protected]>

* Linked requirements to subscription_id check

* Fixed the linked requirements as per review comment

* Removed the unused req

* Adding hyperlink

---------

Co-authored-by: Mickaël Misbach <[email protected]>
  • Loading branch information
punamverma and mickmis authored Feb 2, 2024
1 parent 80475ac commit cac2973
Show file tree
Hide file tree
Showing 7 changed files with 239 additions and 0 deletions.
Empty file.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Original file line number Diff line number Diff line change
@@ -0,0 +1,84 @@
# Requires svg.py 1.4.2

import inspect
from textwrap import dedent
from typing import List

import svg


def translate(points: List[float], dx: float, dy: float) -> List[float]:
result = []
x = True
for p in points:
result.append(p + dx if x else p + dy)
x = not x
return result


outline = "#202020"
accepted = "#808080"
activated = "#00ff00"
nonconforming = "#ffff00"
flight1_points = [20, 30, 20, 200, 70, 200, 140, 120, 190, 200, 250, 200, 250, 30]
flight2_points = [140, 145, 30, 265, 145, 320, 215, 265]


common_elements = [
svg.Style(
text=dedent(""".heavy { font: bold 30px sans-serif; }"""),
),
svg.Marker(
id="arrowhead",
viewBox=svg.ViewBoxSpec(0, 0, 10, 10),
refX=6,
refY=4,
markerWidth=6,
markerHeight=6,
color=outline,
orient="auto-start-reverse",
elements=[
svg.Path(
d=[
svg.MoveTo(0, 0),
svg.LineTo(8, 4),
svg.LineTo(0, 8),
svg.ClosePath(),
],
fill=outline,
)
],
),
]


def make_flight1_activated_flight2_planned():
elements = [
svg.Polygon(
points=flight1_points,
stroke=outline,
fill=activated,
fill_opacity=0.4,
stroke_width=8,
),
svg.Text(x=60, y=100, class_=["heavy"], text="Flight 1"),
svg.Polygon(
points=flight2_points,
stroke=outline,
fill=nonconforming,
fill_opacity=0.4,
stroke_width=8,
),
svg.Text(x=60, y=260, class_=["heavy"], text="Flight 2"),
]

canvas = svg.SVG(
width=400,
height=350,
elements=common_elements + elements,
)
with open(inspect.currentframe().f_code.co_name[len("make_") :] + ".svg", "w") as f:
f.write(str(canvas))


make_flight1_activated_flight2_planned()
Original file line number Diff line number Diff line change
@@ -0,0 +1,116 @@
# Awareness of relevant operational intents test scenario

## Description

When a USS submits an operational intent to DSS, a subscription is associated with that operational intent in DSS.
This subscription can be either an implicit or explicit subscription that covers the area of the operational intent.
The subscription helps the USS to be notified of new or modified operations in the area, when its operational intent is in
Activated, NonConforming and Contingent states. In this scenario, we will verify that USS under test has a subscription
to cover the operational intent area, and receives relevant notifications from other USSes.

- **[astm.f3548.v21.SCD0080](../../../../../requirements/astm/f3548/v21.md)**

This scenario assumes that the area used in the scenario is already clear of any pre-existing flights (using, for instance, PrepareFlightPlanners scenario).

## Resources

### flight_intents

FlightIntentsResource that provides the following flight intents:

<table>
<tr>
<th>Flight intent ID</th>
<th>Flight name</th>
<th>State</th><!-- TODO: Update with usage_state and uas_state when new flight planning API is adopted -->
<th>Must be relevant, but not intersecting</th>
</tr>
<tr>
<td><code>flight_1_planned</code></td>
<td rowspan="2">Flight 1</td>
<td>Accepted</td>
<td rowspan="2">Flight 2</td>
</tr>
<tr>
<td><code>flight_1_activated</code></td>
<td>Activated</td>
</tr>
<tr>
<td><code>flight_2_planned</code></td>
<td>Flight 2</td>
<td>Accepted</td>
<td>Flight 1</td>
</tr>
</table>

To reach a situation where Flight 1 and Flight 2 do not intersect but are relevant to each other:
- their time ranges and altitudes do intersect;
- their geometries do not intersect, but their convex hulls do.

Because the scenario involves activation of intents, all activated intents must be active during the execution of the test scenario. Additionally, their end time must leave sufficient time for the execution of the test scenario. For the sake of simplicity, it is recommended to set the start and end times of all the intents to the same range.

### mock_uss

MockUSSResource will be used for planning flights in order to send notifications to tested_uss, and gathering interuss interactions from mock_uss.

### tested_uss

FlightPlannerResource that will be used for the USS being tested for its ability to maintain awareness of operational intent.

### dss

DSSInstanceResource that provides access to a DSS instance where flight creation/sharing can be verified.

## Activated operational intent receives notification of relevant intent test case

![Test case summary illustration](./assets/flight1_activated_flight2_planned.svg)

This test case verifies that relevant notifications are received through subscription of an operational intent in Activated state.

### Tested_uss plans and activates Flight 1 test step

#### [Plan Flight 1](../../../../flight_planning/plan_flight_intent.md)

Flight 1 should be successfully planned by tested_uss.

#### [Validate Flight 1 sharing](../../validate_shared_operational_intent.md)

#### [Activate Flight 1](../../../../flight_planning/activate_flight_intent.md)

Flight 1 should be successfully activated by the tested USS.

#### [Validate Flight 1 sharing](../../validate_shared_operational_intent.md)

While validating that Flight 1 has been shared, we will be able to find the subscription id associated with Flight 1 in DSS.
Notifications of relevant flights will be sent to tested_uss using this subscription id.

### Mock_uss plans Flight 2 test step

#### [Plan Flight 2](../../../../flight_planning/plan_flight_intent.md)

The test driver successfully plans Flight 2 via the mock uss, as there is no conflict with Flight 1.
However, because they are relevant to each other mock_uss will send Flight 2 notification to tested_uss.

#### [Validate Flight 2 sharing](../../validate_shared_operational_intent.md)

### [Validate Flight 2 notification received by tested_uss test step](../test_steps/validate_notification_received.md)

Check a notification was received by tested_uss for Flight 2, with Flight 1's subscription_id.

## Modify Activated operational intent area and receive notification of relevant intent test case

### ToDo

## Declare Operational intent non-conforming and receive notification of relevant intent test case

### ToDo

## Declare Operational intent contingent and receive notification of relevant intent test case

### ToDo

## Cleanup

### Successful flight deletion check
The flights are cleaned up at the end of the test scenario.
**[interuss.automated_testing.flight_planning.DeleteFlightSuccess](../../../../../requirements/interuss/automated_testing/flight_planning.md)**
Original file line number Diff line number Diff line change
@@ -0,0 +1,38 @@
# Validate notification received test step fragment

This step verifies that a Tested USS successfully received a notification about a relevant operational intent from a Mock USS instance.
This is done by checking the interactions of that Mock USS instance.

## 🛑 Mock USS interactions logs retrievable check
**[interuss.mock_uss.hosted_instance.ExposeInterface](../../../../../requirements/interuss/mock_uss/hosted_instance.md)**.
Mock USS provides a GET endpoint to retrieve all the interactions that took place between Mock USS
and other USSes after a particular time.
If there is any error retrieving these interactions, this check will fail.
These interactions also include the notifications sent and received by Mock USS.

## ⚠️ Mock USS sends valid notification check
There is an assumption here that DSS shared the correct subscriber information with Mock USS in response to planning or modifying its operational intent.

As per **[astm.f3548.v21.USS0005](../../../../../requirements/astm/f3548/v21.md)**,
Mock USS should send valid notification to USSes subscribed in the area.
The validation of notification involves checking that Mock USS included the correct subscription_id in the notification.
The check will fail if the notification to tested USS does not include the expected subscription_id.

## ⚠️ Tested USS receives valid notification check
As per **[astm.f3548.v21.SCD0080](../../../../../requirements/astm/f3548/v21.md)**, USSes shall maintain awareness of
operational intents relevant to their own ones when they are in the Activated, NonConforming or Contingent states.
In DSS, there is a subscription associated with an operational intent managed by a USS. A tested USS should successfully
receive a notification of relevant intent from Mock USS based on this subscription.
The check will be done if valid notification is sent by Mock USS, which is determined in in
**[Mock USS sends valid notification check](#⚠️-mock-uss-sends-valid-notification-check)** above.
This check will fail if tested USS does not respond with http status 204 to a valid notification attempt by Mock USS.

## ⚠️ Tested USS rejects invalid notification check

As per **[astm.f3548.v21.USS0105](../../../../../requirements/astm/f3548/v21.md)**, Tested USS should validate that the notification
received includes the subscription_id associated with its managed operation.
The check will be done if invalid notification is sent by Mock USS, which is determined in
**[Mock USS sends valid notification check](#⚠️-mock-uss-sends-valid-notification-check)** above.
This check will fail if tested USS does not respond with http status 400 for an invalid notification attempt by Mock USS.


0 comments on commit cac2973

Please sign in to comment.