|  Local And sub-Regional ASM System  |

LARA
You are here: Home » What's new » LARA Notice » Notice 04/2020

Notice 04/2020

 LARA NOTICE

 

Number 04/2020

Issued on 10-04-2020

Valid until: UFN

Issued by LARA Team

 

The following LARA Notice describes the list of known issues and applicable corrective measures for the LARA V3.2.0.11 Release:


Issue #1: AUP minimum area opening buffer bridges NAMs. Affected software: LWP and Server

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.

Issue #2: AUP minimum area opening buffer can fail AUP generation. Affected software: LWP and Server

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: This will be fixed to work as intended. This issue is targeted to be fixed in the first V3.2 patch.

Issue #3: Reservation ending early completed and released. Affected software: LWP and Server

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.

Issue #4: BSD base / Linux based Operating Systems require KDE desktop environment. Affected software: LWP, REx, RaMIT


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


In case of any questions please contact the LARA Team

lara@eurocontrol.int

A LARA NOTICE is issued and distributed among LARA Users to inform the LARA Community about observations, important changes and related limitations in regard to the operational use of the LARA Software. Please ensure that relevant personnel is informed about this LARA NOTICE.

 

 


^ Top