If the request is successful, CCS triggers the relevant processing as described below and published the updated SFPL data using the FlightDataDistributionSubscriber Service Interface in order to be displayed in FDO or Controller HMIs.
The SFPL data are updated according to the rules described below.
Standard rule:
Each input optional elementary field shall replace the corresponding one in the SFPL if and only if this field is given in the parameter flightPlanInfo, otherwise the corresponding SFPL field shall be left unchanged:
- fields set: the optional fields that are present in the input are updated in the SFPL.
- fields unchanged: the optional fields that are not present in the input are not updated in the SFPL.
OtherInformation and supplementaryInformation exceptions:
The parameter flightPlanInfo contains optional data otherInformation, supplementaryInformation corresponding to ICAO fields 18 and 19, both provided in a string format.
The operation allows modifying the complete fields 18 and 19.
When otherInformation or supplementaryInformation input data are given, if an optional elementary (sub-)field is not defined in the input data, the corresponding one shall be removed from the SFPL:
- otherInformation (resp. supplementaryInformation) (sub-)fields unchanged: When F18 (resp. 19) is not at all present in the input; the complete corresponding SFPL F18 (resp. 19) field is not updated. I.e. all its (sub-)fields are kept unchanged.
- otherInformation (resp. supplementaryInformation) (sub-)fields set: When F18 (resp. 19) is present in the input; the optional (sub-)fields that are present in input are stored within the corresponding SFPL F18 (resp. 19) field.
- otherInformation (resp. supplementaryInformation) (sub-)fields reset: When F18 (resp. 19) is present in the input; the optional (sub-)fields that are not present in input are reset from the corresponding F18 (resp. 19) field.
On the change of fields which may lead to a new route (Route, ADEP, ADES, RFL, SID, STAR, OTH, ATYP, EQUIP...), CCS must perform the following operations:
- compute the new route,
- update the constraints,
- perform the trajectory computation,
- re-compute the crossed volumes, deduce the crossed ATSUs from the computed SFPL trajectory,
- detect if some segments have been created or have disappeared,
- check the SSR code for the new route,
- update the SFPL and segment states,
- determine the new control and informed responsibility list,
- update the existing coordination data, and determine the coordination data for the new transitions,
- determine the new served Controller list,
- distribute the updated SFPL to the IOP partners if any.
On the change of EOBT/EOBD for a flight which has not departed, CCS re-assesses:
- the delays on the ground,
- the time shift on the computed trajectory,
- the SFPL and segment states due to potential SFPL segment state regression.
On a change of SSR code:
- the previous SSR code and the assigned SSR code are stored in the SFPL, for relevant SFPL segments.
- CCS checks the validity of the new SSR code and the potential duplication.
- CCS re-assesses the classification of the coordinations and potential automatic coordination rejections.
Route modification:
It is not possible to process a route amendment via this operation (for this purpose refer to the operation requestProcessRoute).
The requestNonTacticalModification operation allows changing the whole reference route (ICAO F15 c), not a portion of the route. The change of F15 C ICAO field, even if the change impacts only a portion of it, is processed by the system as a change of the whole reference route and makes invalid all the constraints input on the SFPL.
The trajectory is recomputed according to the new F15-C if the flight is non departed. If the flight is departed, the input is rejected by CCS (i.e. it is either rejected or sent to FDO as applicable).
Both F15a and F15b can be changed via this operation even if part of trajectory points are overflown.