Introduction
Because we are all different, the implementation of an effective Airport Management System (AMS) can be a complex process. To capture the relevant management data at the right time, bespoke interfaces for the various airfield systems are required. A primary data source for all activities around the airfield for the AMS is the Air Traffic Control (ATC) System. In-Bound and Out-Bound flights are the pegs upon which many of the related service charges are applied. To a number of commercially available AMS, the ATC world is either difficult to access or simply not available. The Copperchase ATC Data System now provides a defined interface for an AMS and because most of these AMS are now offered as Cloud Services, the Copperchase ATC-AMS Interface is also available on-line.
The Copperchase ATC-AMS interface makes real-time ATC data available to allow an AMS to monitor/track movements, monitor fees paid/unpaid (prior to DEP) and maintain elements such as a Flight Information Display.
Technical
The Copperchase ATC-AMS Interface allows for flight data to be extracted from the Copperchase ATC Data System via a RESTful API.
The Copperchase ATC-AMS Interface is available via a Uniform Resource Locator (URL) which will be disclosed in full to each site.
The Copperchase ATC-AMS Interface will accept HTTPS requests to its “touch-points” described further in an Interface Control Document (ICD).
Data Outbound Flow
The Copperchase ATC-AMS Interface provides GET touch-points through which the subscriber application can request flight data. There are various GET touch-points depending on the request parameters required.
Once a successful GET request has been made, flight data in XML or JSON format will be returned to the subscriber.
Data Inbound Flow
The Copperchase ATC-AMS Interface provides no data import facilities. But it does provide the facility to modify FDMS Movement Log data.
The Copperchase ATC-AMS Interface provides a PUT touch-point, through which a subscriber can mark ATC Data System Movements as no longer required in any future requests. That means that a subscriber application can mark a given log entry as no longer needed, and which should be ignored by any further requests for data.