LARA Notice 04/2020

Description: When generating an AUP/UUP, the “minimum area opening time” can be set. This bridges reservation gaps to close areas, and therefore affected routes, which would otherwise be available for too short a time. It is intended for reservations but is incorrectly bridging NAM activities. This can affect the AUP/UUP Charlie/Delta sections, placing the NAM bridge into Charlie, which can then fail the AUP/UUP import, rejecting due to a Charlie mismatch.

Reproduction steps:

• Create a NAM area with timesheets every day containing a small gap (e.g., timesheets up to 12:00 and then again from 12:30, leaving a thirty-minute gap).
• Create an AUP for a day setting the minimum area opening time to one hour.
• A bridge usage 12:00-12:30 for the NAM is generated but placed in Charlie.
• Exporting/importing this AUP to/from ACA format fails with a validation error.

Prevention: To avoid this issue, ensure that NAM activities are not bridged. This can be done by either:

• not using the minimum area opening time setting or
• not having AUPable NAMs or
• ensuring the gaps in NAM timesheets are larger than any minimum area opening time used.

Fix: This will be fixed by preventing bridges from being created between NAM activities. The fix is targeted to be fixed in the first V3.2 patch.

Description: When generating an AUP/UUP, the “minimum area opening time” can be set. This bridges reservation gaps to close areas, and therefore affected routes, which would otherwise be available for too short a time. In some cases, use of this functionality can cause AUP/UUP generation to fail.

Reproduction steps:

• Set up an AUPable area with an FBZ which is enabled by default. The FBZ should have a crossing or nearby relationship to an AUPable CDR segment.
• Create reservations to be bridged with a thirty-minute gap between them (e.g., 12:00-13:00 and 13:30-14:30).
• Create an AUP for the day of the reservations setting the minimum area opening time to one hour.
• The generation fails recording an error on the Server.

Prevention: To avoid this issue, ensure that such an area/FBZ/CDR segment setup is not bridged. This can be done by either:

• not using the minimum area opening time setting or
• not having such a setup or
• ensuring the gaps in reservation on such areas are larger than any minimum area opening time used.

Fix: his will be fixed to work as intended. This issue is targeted to be fixed in the first V3.2 patch.

Description: When ending a reservation early which has an airspace release in effect, the reservation will complete but the release can sometimes stay active. This causes the airspace status to be inactive but marked as released.

Reproduction steps:

• Create a reservation with a release and wait until so that the release is in effect.
• End the reservation early.
• The airspace deactivates.
• Sometimes the airspace is correctly not marked as released, but sometimes it is incorrectly marked as released.

Prevention: To avoid this issue, do not end reservations early which have an active release. Instead either:

• edit the reservation to end in a short period of time (e.g., one minute), automatically shortening the release or
• end the release and then the reservation.

If it has already happened, then restarting the server resets the release to the correct state.

Fix: This will be fixed to work as intended. This issue is targeted to be fixed in the first V3.2 patch.

Description: Although previous releases of LARA were running on multiple platforms, non-KDE desktop environments, such as e.g. GNOME will not allow to run the graphical interface of LARA modules.

Prevention: Run LARA clients exclusively with either MS-Windows either OS supporting KDE desktop environment.

Fix: This issue has been identified, described and its resolution can be monitored in MANTIS #4061.