-
Notifications
You must be signed in to change notification settings - Fork 20
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
[uss_qualifier] Add scenario for testing data validation by SUT for Get operational_intent #293
Merged
BenjaminPelletier
merged 29 commits into
interuss:main
from
punamverma:first_data_validation_scenario
Nov 3, 2023
Merged
Changes from all commits
Commits
Show all changes
29 commits
Select commit
Hold shift + click to select a range
9bbecfb
Scenario for testing data validation by SUT for Get operational_intent
punamverma 1fd83d5
Removing an import
punamverma 5d618a2
Fix format
punamverma 56e0e8b
Add interactions requirement file
punamverma 427cdf7
Adding more description to the scenario
punamverma 2dddc76
Scenario documentation fix
punamverma db471a0
Improved requirements description
punamverma fdc3c7f
Per PR comments, fixed module path, file name, checks and description…
punamverma 572bfeb
Per PR comments removing py files, and improving description
punamverma 246cd3f
Per PR review, created a new requirement for no notifications
punamverma d322d0a
Adding empty sceanrio and fixing documentation links
punamverma 493247b
Fix format
punamverma 9f46935
Fix the requirement reference in documentation
punamverma be300fa
Documentation change per PR
punamverma 52f1308
Removed requirement reference from test step, as per PR review
punamverma 42f337a
Added more description to test steps
punamverma bfda3e3
Fix per PR review
punamverma a298f4d
Merge branch 'main' into first_data_validation_scenario
punamverma 43c2b3d
Removed time_range suffix for flight intents, as per PR comment
punamverma 4a3df76
Remover time_range_A suffix from flight intent
punamverma ae54279
Revert "Remover time_range_A suffix from flight intent"
punamverma 9dc0912
Removed time_range_A suffix from flight intents
punamverma e58a0fe
Removing unreferenced file and description per PR review
punamverma 2b68ef5
fixing variable name per PR reveiw
punamverma dbcb318
Removed link for no notification pushed
punamverma 4ae2814
Fixed removing link
punamverma 5dc2375
Fix link
punamverma 23141b2
Removing check from a precondition step as per PR review
punamverma 7e3ffcb
Merge branch 'main' into first_data_validation_scenario
punamverma File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
9 changes: 9 additions & 0 deletions
9
monitoring/uss_qualifier/requirements/interuss/f3548/notification_requirements.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,9 @@ | ||
# ASTM F3548-21 notifications requirement | ||
|
||
While ASTM F3548-21 does not specifically prohibit sending notifications for operational intent changes when those notifications were not specifically prescribed by a notification that an operational intent may be relevant to a subscription (response from the DSS), InterUSS expects that notifications will only be sent at these particular times. | ||
SCD0085 requirement states only a positive requirement (preconditions satisified => notification must be sent). | ||
It doesn't establish a negative requirement (preconditions not satisfied => no notifications may be sent). | ||
As these negative requirements are reasonable and related to SCD0085, interUSS has added it as a requirement for testing. | ||
This can happen in following situations - | ||
* <tt>NoDssEntityNoNotification</tt> If a USS was unable to write an entity reference to the DSS, it should not erroneously notify that operational intent, to another USS subscribed in the area. | ||
* <tt>NoSubscriptionNoNotification</tt> If a USS wrote an entity reference to the DSS, and was notified of no other USS subscription, then it should not send a notification to any USS. So the USS shall (OnlyPrescribedNotifications) only send operational intent notifications when prescribed by SCD0085. |
Empty file.
112 changes: 112 additions & 0 deletions
112
...qualifier/scenarios/astm/utm/data_exchange_validation/get_op_data_validation.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,112 @@ | ||
# Data Validation of GET operational intents by USS test scenario | ||
|
||
## Description | ||
This test checks that the USS being tested validates the operational intents received as response to its GET request from another USS. | ||
Control_uss which is a mock uss plans a nearby V-shaped operation, and provides the data that tested_uss GETs. | ||
tested_uss validates the GET response from control_uss and accordingly plan its operation. | ||
Notably the following requirements: | ||
|
||
- **[astm.f3548.v21.SCD0035](../../../../requirements/astm/f3548/v21.md)** | ||
|
||
## Resources | ||
### flight_intents | ||
FlightIntentsResource provides the two V-shaped flight intents. | ||
The convex hulls of the 2D footprints of the two flights intersect, but the polygons do not intersect. | ||
There is an overlap in time and altitude of the two flights. | ||
- flight_1 | ||
- flight_2 | ||
|
||
### control_uss | ||
MockUSSResource that will be used for planning flights, controlling data shared for validation testing, and gathering interuss interactions from mock_uss. | ||
|
||
### tested_uss | ||
FlightPlannerResource that will be used for the USS being tested for its data validation of operational intent. | ||
|
||
### dss | ||
DSSInstanceResource that provides access to a DSS instance where flight creation/sharing can be verified. | ||
|
||
## Setup test case | ||
### Check for flight planning readiness test step | ||
Both USSs are queried for their readiness to ensure this test can proceed. | ||
|
||
#### Flight planning USS not ready check | ||
If either USS does not respond appropriately to the endpoint queried to determine readiness, this check will fail and the USS will have failed to meet **[astm.f3548.v21.GEN0310](../../../../requirements/astm/f3548/v21.md)** as the USS does not support the InterUSS implementation of that requirement. | ||
|
||
### Area clearing test step | ||
Both USSs are requested to remove all flights from the area under test. | ||
|
||
#### Area cleared successfully check | ||
**[interuss.automated_testing.flight_planning.ClearArea](../../../../requirements/interuss/automated_testing/flight_planning.md)** | ||
|
||
## Successfully plan flight near an existing flight test case | ||
|
||
### [Control_uss plans flight 2 test step](../../../flight_planning/plan_flight_intent.md) | ||
Flight 2 should be successfully planned by the control USS. | ||
|
||
### [Validate flight 2 sharing test step](../validate_shared_operational_intent.md) | ||
Validate that flight 2 is planned | ||
|
||
### Precondition - check tested_uss has no subscription in flight 2 area test step | ||
In order to run this test scenario, we need tested_uss to trigger GET operational intent request to mock_uss. | ||
So we need to make sure that there is no subscription of tested_uss, that would trigger notification of flight 2 to tested_uss. | ||
No notification pushed by control_uss to tested_uss, will ensure that tested_uss will make a GET request to control_uss for flight 2 details, | ||
while planning a nearby flight. | ||
If a notification is sent to tested_uss, the precondition for running this scenario will not be satisfied. | ||
|
||
### [Tested_uss plans flight 1 test step](../../../flight_planning/plan_flight_intent.md) | ||
The test driver attempts to plan flight 1 via the tested USS. It checks if any conflicts with flight 2 | ||
which is of equal priority and came first. | ||
|
||
### [Validate flight 1 sharing test step](../validate_shared_operational_intent.md) | ||
Validate flight 1 is planned. | ||
|
||
### [Validate flight2 GET interaction test step](test_steps/validate_get_operational_intent.md) | ||
Validate that tested_uss makes a GET request for obtaining details of flight 2 from control_uss. | ||
In a previous step (Precondition - check tested_uss has no subscription in flight 2 area), we ensured that no notification of flight 2 was sent to tested_uss. | ||
Hence, tested_uss will need to make a GET request to obtain flight 2 details. | ||
|
||
### [Validate flight1 Notification sent to Control_uss test step](test_steps/validate_notification_operational_intent.md) | ||
Tested_uss notifies flight 1 to Control_uss, due to its subscription through flight 2. | ||
|
||
### [Delete tested_uss flight test step](../../../flight_planning/delete_flight_intent.md) | ||
Teardown | ||
|
||
### [Delete control_uss flight test step](../../../flight_planning/delete_flight_intent.md) | ||
Teardown | ||
|
||
## Flight planning prevented due to invalid data sharing test case | ||
### [Control_uss plans flight 2, sharing invalid operational intent data test step](../../../flight_planning/plan_flight_intent.md) | ||
Flight 2 should be successfully planned by the control_uss. | ||
The control_uss, which is mock_uss is instructed to share invalid data with other USS, for negative test. | ||
|
||
### [Validate flight 2 shared operational intent with invalid data test step](test_steps/validate_sharing_operational_intent_but_with_invalid_interuss_data.md) | ||
Validate that flight 2 is shared with invalid data as a modified behavior is injected by uss_qualifier for a negative test. | ||
|
||
### Precondition - check tested_uss has no subscription in flight 2 area test step | ||
In order to run this test scenario, we need tested_uss to trigger GET operational intent request to mock_uss. | ||
So we need to make sure that there is no subscription of tested_uss, that would trigger notification of flight 2 to tested_uss. | ||
No notification pushed by control_uss to tested_uss, will ensure that tested_uss will make a GET request to control_uss for flight 2 details, | ||
while planning a nearby flight. | ||
If a notification is sent to tested_uss, the precondition for running this scenario will not be satisfied. | ||
|
||
### [Test_uss attempts to plan flight 1, expect failure test step](test_steps/plan_flight_intent_expect_failed.md) | ||
The test driver attempts to plan the flight 1 via the tested_uss. It checks if any conflicts with flight 2 | ||
which is of equal priority and came first. | ||
|
||
### [Validate flight 1 not shared by tested_uss test step](../validate_not_shared_operational_intent.md) | ||
Validate flight 1 is not shared with DSS, as plan failed. | ||
|
||
### [Validate flight 2 GET interaction test step](test_steps/validate_get_operational_intent.md) | ||
Validate that tested_uss makes a GET request for obtaining details of flight 2 from control_uss. | ||
In a previous step (Precondition - check tested_uss has no subscription in flight 2 area), we ensured that no notification of flight 2 was sent to tested_uss. | ||
Hence, tested_uss will need to make a GET request to obtain flight 2 details. | ||
|
||
### [Validate flight 1 Notification not sent to Control_uss test step](test_steps/validate_no_notification_operational_intent.md) | ||
|
||
### [Delete Control_uss flight test step](../../../flight_planning/delete_flight_intent.md) | ||
Teardown | ||
|
||
## Cleanup | ||
### Successful flight deletion check | ||
This cleanup is for both - after testcase ends and after test scenario ends | ||
**[interuss.automated_testing.flight_planning.DeleteFlightSuccess](../../../../requirements/interuss/automated_testing/flight_planning.md)** |
52 changes: 52 additions & 0 deletions
52
...oring/uss_qualifier/scenarios/astm/utm/data_exchange_validation/get_op_data_validation.py
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,52 @@ | ||
from typing import Optional | ||
|
||
from monitoring.uss_qualifier.resources.astm.f3548.v21 import DSSInstanceResource | ||
from monitoring.uss_qualifier.resources.astm.f3548.v21.dss import DSSInstance | ||
from monitoring.uss_qualifier.resources.flight_planning import ( | ||
FlightIntentsResource, | ||
) | ||
from monitoring.uss_qualifier.resources.flight_planning.flight_intent import ( | ||
FlightIntent, | ||
) | ||
from monitoring.uss_qualifier.resources.flight_planning.flight_planner import ( | ||
FlightPlanner, | ||
) | ||
from monitoring.uss_qualifier.resources.flight_planning.flight_planners import ( | ||
FlightPlannerResource, | ||
) | ||
|
||
from monitoring.uss_qualifier.scenarios.scenario import ( | ||
TestScenario, | ||
) | ||
|
||
from monitoring.uss_qualifier.resources.interuss.mock_uss.client import ( | ||
MockUSSClient, | ||
MockUSSResource, | ||
) | ||
|
||
|
||
class GetOpResponseDataValidationByUSS(TestScenario): | ||
flight_1: FlightIntent | ||
|
||
flight_2: FlightIntent | ||
|
||
tested_uss: FlightPlanner | ||
control_uss: MockUSSClient | ||
dss: DSSInstance | ||
|
||
def __init__( | ||
self, | ||
tested_uss: FlightPlannerResource, | ||
control_uss: MockUSSResource, | ||
dss: DSSInstanceResource, | ||
flight_intents: Optional[FlightIntentsResource] = None, | ||
): | ||
super().__init__() | ||
self.tested_uss = tested_uss.flight_planner | ||
self.control_uss = control_uss.mock_uss | ||
self.dss = dss.dss | ||
|
||
def run(self): | ||
self.begin_test_scenario() | ||
pass | ||
self.end_test_scenario() |
Empty file.
14 changes: 14 additions & 0 deletions
14
...stm/utm/data_exchange_validation/test_steps/plan_flight_intent_expect_failed.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,14 @@ | ||
# Plan flight Expect Failed test step | ||
|
||
This page describes the content of a common test case where a valid user flight intent fails in a flight planner, because of invalid data shared for a nearby flight shared by another USS. See `plan_flight_intent_expect_failed` in invalid_op_test_steps.py. | ||
|
||
## Plan should fail check | ||
|
||
A USS shouldn't go ahead and plan if it doesn't have accurate information. | ||
As per SCD0035 a USS needs to verify a particular conflict status. | ||
If flight intent data shared for a nearby flight shared is invalid, the USS can't successfully perform that verification. | ||
It couldn't have obtained valid information about the other operational intents it's supposed to verify that conflict status against. | ||
Therefore, the USS should fail an attempt to plan. If the plan succeeds, we know they've violated SCD0035 because they failed to verify that particular conflict status. | ||
|
||
**[astm.f3548.v21.SCD0035](../../../../../requirements/astm/f3548/v21.md)** | ||
|
10 changes: 10 additions & 0 deletions
10
...astm/utm/data_exchange_validation/test_steps/validate_get_operational_intent.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,10 @@ | ||
# Validate GET interaction test step | ||
|
||
This step verifies that a USS makes a GET request to get the intent_details of an existing operation when needed as per ASTM F3548-21 by checking the interuss interactions of mock uss | ||
|
||
## MockUSS interactions request check | ||
**[interuss.mock_uss.hosted_instance.ExposeInterface](../../../../../requirements/interuss/mock_uss/hosted_instance.md)**. | ||
|
||
## Expect GET request check | ||
**[astm.f3548.v21.SCD0035](../../../../../requirements/astm/f3548/v21.md)** | ||
SCD0035 needs a USS to verify before transitioning to Accepted that it does not conflict with a type of operational intent, and the only way to have verified this is by knowing all operational intent details, and (from previous checks of no notifications) the only way to know the operational intent details of flight is to have requested them via a GET details interaction. |
10 changes: 10 additions & 0 deletions
10
...a_exchange_validation/test_steps/validate_no_notification_operational_intent.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,10 @@ | ||
# Validate no notification test step | ||
|
||
This step verifies when a flight is not created, it is also not notified by checking the interuss interactions of mock_uss instance. | ||
|
||
## MockUSS interactions request check | ||
**[interuss.mock_uss.hosted_instance.ExposeInterface](../../../../../requirements/interuss/mock_uss/hosted_instance.md)**. | ||
|
||
## Expect Notification not sent check | ||
|
||
**[interuss.f3548.notification_requirements.NoDssEntityNoNotification](../../../../../requirements/interuss/f3548/notification_requirements.md)** |
12 changes: 12 additions & 0 deletions
12
...data_exchange_validation/test_steps/validate_notification_operational_intent.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,12 @@ | ||
# Validate notification test step | ||
|
||
This step verifies that, when creating or modifying an operational intent, a USS sent the required notification for a relevant subscription owned by a mock_uss instance by checking the interactions of that mock_uss instance. | ||
|
||
## MockUSS interactions request check | ||
**[interuss.mock_uss.hosted_instance.ExposeInterface](../../../../../requirements/interuss/mock_uss/hosted_instance.md)**. | ||
|
||
## Expect Notification sent check | ||
**[astm.f3548.v21.SCD0085](../../../../../requirements/astm/f3548/v21.md)** | ||
|
||
## Notification data is valid check | ||
**[astm.f3548.v21.SCD0085](../../../../../requirements/astm/f3548/v21.md)** |
23 changes: 23 additions & 0 deletions
23
...est_steps/validate_sharing_operational_intent_but_with_invalid_interuss_data.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,23 @@ | ||
# Validate flight sharing invalid data test step | ||
|
||
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See `expect_shared_with_invalid_data` in invalid_op_test_steps.py. | ||
|
||
## DSS responses check | ||
|
||
**[astm.f3548.v21.DSS0005](../../../../../requirements/astm/f3548/v21.md)** | ||
|
||
## Operational intent shared with DSS check | ||
|
||
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per **[astm.f3548.v21.USS0005](../../../../../requirements/astm/f3548/v21.md)** and **[astm.f3548.v21.OPIN0025](../../../../../requirements/astm/f3548/v21.md)**. | ||
|
||
## Operational intent details retrievable check | ||
|
||
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per **[astm.f3548.v21.USS0105](../../../../../requirements/astm/f3548/v21.md)** and **[astm.f3548.v21.OPIN0025](../../../../../requirements/astm/f3548/v21.md)**. | ||
|
||
## Invalid data in Operational intent details shared by Mock USS for negative test check | ||
|
||
Mock USS shares operational intent details response for the negative test case as per [the GetOperationalIntentDetailsResponse schema of the OpenAPI specification](https://github.com/astm-utm/Protocol/blob/v1.0.0/utm.yaml#L1120). | ||
If the operational intent details from mock_uss is valid, this check will fail. It would mean mock_uss is not behaving correctly. | ||
**[interuss.mock_uss.hosted_instance.ExposeInterface](../../../../../requirements/interuss/mock_uss/hosted_instance.md)**. | ||
|
||
|
106 changes: 106 additions & 0 deletions
106
monitoring/uss_qualifier/test_data/usa/kentland/flight_intents/non_conflicting.yaml
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,106 @@ | ||
intents: | ||
flight_1: | ||
full: | ||
basic_information: | ||
usage_state: Planned | ||
uas_state: Nominal | ||
area: | ||
- outline_polygon: | ||
vertices: | ||
- lat: 37.20642344604623 | ||
lng: -80.58508994131496 | ||
- lat: 37.21359527809636 | ||
lng: -80.5767365824006 | ||
- lat: 37.215812746083586 | ||
lng: -80.58144645497978 | ||
- lat: 37.2146332499489 | ||
lng: -80.58408279875103 | ||
altitude_lower: | ||
value: 474 | ||
reference: W84 | ||
units: M | ||
altitude_upper: | ||
value: 560 | ||
reference: W84 | ||
units: M | ||
start_time: | ||
offset_from: | ||
starting_from: | ||
start_of_test: { } | ||
offset: -1s | ||
duration: 5m | ||
|
||
astm_f3548_21: | ||
priority: 0 | ||
|
||
uspace_flight_authorisation: | ||
uas_serial_number: 1AF49UL5CC5J6K | ||
operation_category: Open | ||
operation_mode: Vlos | ||
uas_class: C0 | ||
identification_technologies: | ||
- ASTMNetRID | ||
connectivity_methods: | ||
- cellular | ||
endurance_minutes: 30 | ||
emergency_procedure_url: https://example.interussplatform.org/emergency | ||
operator_id: CHEo5kut30e0mt01-qwe | ||
uas_id: '' | ||
uas_type_certificate: '' | ||
|
||
|
||
flight_2: | ||
full: | ||
basic_information: | ||
usage_state: Planned | ||
uas_state: Nominal | ||
area: | ||
- outline_polygon: | ||
vertices: | ||
- lat: 37.214119359044275 | ||
lng: -80.58443600701524 | ||
- lat: 37.212388260776436 | ||
lng: -80.58824885811198 | ||
- lat: 37.20211436858821 | ||
lng: -80.5856832012991 | ||
- lat: 37.21394908884487 | ||
lng: -80.57474352572189 | ||
- lat: 37.206173006943104 | ||
lng: -80.5852199577081 | ||
altitude_lower: | ||
value: 483 | ||
reference: W84 | ||
units: M | ||
altitude_upper: | ||
value: 519 | ||
reference: W84 | ||
units: M | ||
start_time: | ||
offset_from: | ||
starting_from: | ||
start_of_test: { } | ||
offset: -1s | ||
duration: 5m | ||
|
||
astm_f3548_21: | ||
priority: 0 # TODO: Remove flight_authorisation section when it is optional | ||
|
||
uspace_flight_authorisation: | ||
uas_serial_number: 1AF49UL5CC5J6K | ||
operation_category: Open | ||
operation_mode: Vlos | ||
uas_class: C0 | ||
identification_technologies: | ||
- ASTMNetRID | ||
connectivity_methods: | ||
- cellular | ||
endurance_minutes: 30 | ||
emergency_procedure_url: https://example.interussplatform.org/emergency | ||
operator_id: CHEo5kut30e0mt01-qwe | ||
uas_id: '' | ||
uas_type_certificate: '' | ||
|
||
|
||
|
||
|
||
|
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: The successful mock_uss interactions retreival check will probably still be valid here, but we can add marginal/additional checks at implementation time -- that's not a core check of the scenario, so no need to change before merging this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok. So, should we raise an exception for mock_uss interaction retrieval check and notification not sent? And accordingly continue or stop the scenario.