Test Lara v3.0

Access acceptance activities for Lara v3.0 client application

18/07/2016-20/07/2016

04/07/2017

AUP/UUP-Scenario1: Check ‘AUP management’ capabilities

Scenario 1 (Draft) CIAM results

Scenario 1 (Ready) LARA view

Scenario 1 (READY) CIAM results

Scenario 1 demote to DRAFT LARA view

Conclusion:

As expected client application is able to handle draft status.

Scenario 1 demote to draft CIAM view

Scenario1 +3.3: overlaps in time with deconfliction ON

AUP/UUP-Scenario2: Check ‘UUP management’ capabilities

See Scenario 4.2 Synchronization with NM after release of AUP (corrective UUP).

AUP/UUP-Scenario3: Check overlaps

Scenario 3.1

Objective Content FL and WEF-TIL Restriction Expected

3.1 Issue a NIL AUP No error, proper Remark field.

3.1 Issue NIL AUP – LARA view1/2

3.1 Issue NIL AUP - LARA view2/2

3.1 Issue NIL AUP – CIAM results view

Conclusion:

As expected, no error, proper Remark field.

Scenario 3.2Objective Content FL and WEF-TIL Restriction Expected

3.2 Issue AUP featuring a RSA activation for which there is no NOTAM

EETSA15B Get the Warning “There is no NOTAM closure corresponding to the AUP/UUP closure

3.2 NOTAM warning –LARA view

Conclusion :

As expected, client application Get the Warning “There is no NOTAM closure corresponding to the AUP/UUP closure.

3.2 NOTAM warning –CIAM Results view

Scenario 3.3Content FL

and WEF-TILRestriction Expected

3.3 Issue UUP and include a RSA less than 3 hours in advance

EETSA15B (FL095-UNL; 0800-1100)

Get the warning RSA allocation(RSA ID) is less than 3 hours after planned UUP publication

3.3 Issue UUP and include a RSA less than 3 hours in advance

Conclusion:

Get the appropriate warning message route closure less than 3 hours after planned UUP publication.

Scenario 3.4Objective Content FL

and WEF-TILRestriction Expected

3.4 Overlaps in time only

EETSA7

EETSA7

(FL095-UNL; 0800-1100)

(FL095-UNL; 0900-1200)

The Client application is able to display RSA allocation error due to the overlap or NM is able to receive unambiguous information.

3.4: Overlaps in time – LARA view with de-confliction OFF

Conclusion: 2 missions in client application with de-confliction option OFF results in an ERROR message, as per NM requirement.NOTE: LARA v3.0 client application has a de-confliction function that can be enabled/disabled as per local requirement. The following slides show the results with de-confliction function ON.

3.4: overlaps in time – LARA viewwith de-confliction ON

3.4: overlaps in time – CIAM results view with de-confliction ON

Conclusion:

Two missions in client application with de-confliction option ON results in one single booking complies with FUA/CADF requirements

Scenario 3.5

Objective Content FL and WEF-TIL

Restriction Expected

3.5 Overlaps in Time +FL

EETSA7

EETSA7

(FL095-245; 1430-1530)

(FL195-245; 1430-1730)

The Client application is able to display RSA allocation error due to the overlap or NM is able to receive unambiguous information.

3.5 Overlaps in FL- LARA view with de-confliction ON

3.5 Overlaps in FL- CIAM results view with de-confliction ON

Conclusion:

Two missions in client application featuring overlaps in FL description results in appropriate non ambiguous 2 bookings that complies with FUA/CADF requirements.

Scenario 3.6Objective Content FL

and WEF-TILRestriction Expected

3.6 Overlaps of FBZ with corresponding owner RSA

EETSA7Z

EETSA7

(FL095-225; 1430-1530)

(FL175-225; 1430-1730)

EETSA7ZRA:Y EETSA7ZRB:Y

The Client application is able to display RSA allocation error due to the overlap or NM is able to receive unambiguous information.

3.6 Overlaps of FBZ with corresponding owner RSA

Conclusion:

Get the expected RSA allocation error message (Overlaps of FBZ with corresponding owner RSA) or split allocations.

Scenario 3.7Objective Content FL

and WEF-TILRestriction Expected

3.7 Overlaps geometry with FBZOverlaps in geometry (same time but overlapping horizontal definition)

EETSA15AZ

EETSA15B

EETSA15CZ

(FL095-500; 0900-1100)

(FL095-305, 0900-1100)

(FL095-305, 0900-1100)

EETSA15AZR:Y EETSA15AZS:N

-EETSA15ZR:Y

EETSA15AZS:N

Get the Warning about geometrically overlapping area.

3.7 Overlaps geometry with FBZ

Conclusion:

Get the expected Warning about geometrically overlapping area.

3.7 Overlaps geometry with FBZ

Scenario 3.8Objective Content FL

and WEF-TILRestriction Expected

3.8 check the outcomes for FUA/EU restrictions overlapping

EBTRANA (FL045 -195)08:00-12:00

EBTRANAR: YEBTRANAS: NEBTRANAT : Y

The Client application is able to display RSA allocation error due to the overlap or NM is able to receive unambiguous information.

EBTRANA (045 -195)

10:00 -13:00

EBTRANAR: N

EBTRANAS: Y

EBTRANAT : N

3.8 Overlaps in FL- CIAM results view with de-confliction OFF

Conclusion: 2 missions in client application with de-confliction option OFF results in an ERROR message, as per NM requirement.NOTE: The following slides show the results with de-confliction function ON.

3.8 Overlaps in FL- CIAM results view with de-confliction ON

Conclusion:

Two missions in client application with de-confliction option ON results in one single booking complies with FUA/CADF requirements

3.8 Overlaps in FL- CIAM results view with de-confliction ON

3.8 Overlaps in FL- CIAM results view with de-confliction ONReady status

Analysis:

LARAv3.0 workflow is the following:

1. Reservation of the airspace

2. Generation of the AUP: at this step the de-confliction is applied: it results in a single booking in this case.

3. Then the operator selects the restriction he wants to apply. As there is only one airspace reservation, it forbids the overlapping in restriction.

1.

2.

3.

The operator clicks on FUA/EU to select the restriction among the one available: in this particular case• EBTRANAR• EBTRANAS• EBTRANAT

3.8 Overlaps in FL- CIAM results view with de-confliction ON

Conclusion:

• the de-confliction is applied on the airspace reservation before any restriction is applied to it.

• As the result, LARA v3.0 cannot produces any overlaps in the applied restrictions, as they are applied on the “de-conflicted” reserved airspace(s).

• 2 missions in client application with de-confliction option ON results in one single booking complies with FUA/CADF requirements.

AUP/UUP-Scenario4: Synchronization with NM and take over capabilities in case of service unavailability.

Scenario 4.1 Synchronization with NM before release of AUP

Scenario 4.1 Synchronization with NM before release of AUP

1st Aup produced by NM

Scenario 4.1 Synchronization with NM before release of AUP

1st Aup produced by NM

Scenario 4.1 Synchronization with NM before release of AUP

Client application is (re)started and synchronises with NM data.

It gets a notification there is different AUP known by NM

Scenario 4.1 Synchronization with NM before release of AUP

Client application promotes the updated AUP.

Scenario 4.1 Synchronization with NM before release of AUP

Conclusion: LARA v3.0 is able to synchronise, take over and produce an AUP let by NM in draft.

Scenario 4.2 Synchronization with NM after release of AUP (corrective UUP).

Scenario 4.2 Synchronization with NM after release of AUP (corrective UUP).

Scenario4 part2creation of UUP10 by NM on behalf on the AMC

Scenario 4.2 Synchronization with NM after release of AUP (corrective UUP).

The UUP 10 published by NM is retrieved.

It gets a notification there is different AUP known by NM

Scenario 4.2 Synchronization with NM after release of AUP (corrective UUP).

AMC takes over and issue a new UUP11

Scenario 4.2 Synchronization with NM after release of AUP (corrective UUP) - results in CADF.

AMC takes over and issue a new UUP11.

Scenario 4.2 Synchronization with NM after release of AUP (corrective UUP).

Conclusion:

LARA v3.0 is able to synchronise, take over and produce an UUP after AUP has been published by NM.