The CREWS application runs on standard PCs running Windows XP. The next Microsoft operating systems are being finalized (Windows VISTA, Windows Seven).
Find out more: CREWS
 

There is no limit to the integration of DCS systems in the CREWS application, regardless of the communication protocol used (TCP/IP, UTS, ALC, etc.).
Information on integrated applications is available on request.
Find out more: info@resa.fr
 

CREWS has an unlimited capacity to integrate airline applications. Integration of any new airline is extremely smooth. We provide airlines with high level API’s that facilitate the application integration process.
Information on integrated applications is available on request.
Find out more: info@resa.fr
 

CREWS fully supports 2D barcode technology, which will replace magnetic ATB technology by 2010. In 2006 we developed the software components needed to implement this new technology and certified several machines for printing and reading 2D barcodes.
Find out more: CREWS
 

In January 2007, the Basel-Mulhouse airport, with 140 check-in counters and gates, selected RESA and our CREWS 2D application to replace their existing CUTE system. This 100% 2D barcode platform serves more than 4 million passengers and handles more than 20 airlines.
Find out more: CREWS
 

Yes, we are already testing all the peripherals that deliver this new technology in order to be able to meet airport requirements when the time comes.
Find out more: CREWS
 

Yes, we contribute actively to defining new CUPPS standards and participate in numerous tasks forces to define future market standards.
Find out more: CUPPS
 

CUPPS (Common Use Passenger Processing Systems) is a revised version of CUTE (Common Use Terminal Equipment – Recommended Practice 1797) which redefines the IATA Recommended Practice dating from 1994.
This Recommended Practice has also been approved by the ACI (Airports Council International - ACI’s RP 500A07) and ATA (Air Transport Association - ATA’s TP 30.201).
Find out more: CUPPS recommended practice
 

Yes, IATA work groups continuously work on developing the Recommended Practice.
Currently, several versions are generated each year according to the work's progress. In the long term, there will always be one version each year which will take any necessary developments into account.
The life span of a published version is 3 years.
Find out more: CUPPS
 

CREWS CUPPS enables airports:
- to benefit from new supervision tools which are more user-friendly and powerful;
- to accommodate airlines' CUPPS applications;
- to make new peripheral devices available (such as automatic boarding gates) with the guarantee of making them profitable as they can be shared by all airlines;
- to use the airport/host connection for sending IATA messages, thus saving on dedicated connections.
 

CUPPS technical specifications define:
- network recommendations (speed, protocols, security, etc.);
- PCI/DSS compatibility recommendations
(security rules for environments using payment methods in particular);
- the minimum technical characteristics for equipment (workstation power, touch screen, peripheral device functions, compatibility with AEA 2008/2009, etc.).

 

Yes, RESA received CUPPS certification on October 15, 2009. RESA's CUTE CREWS system has become the world's leading CUPPS system, installed in an international hub (Brussels Airport), to be approved and used operationally by two airlines (Lufthansa and Iberia), without reservation and under the control of an external certification body (LH Systems).
 

Certifying a platform involves different phases which must be performed in the following order:
- "Compliance testing": validation by an external certification body (CTE) of the platform's correct operation. This phase consists of performing various test scenarios designed to cover the functions described in the IATA specifications. RESA chose Lufthansa Systems - a certification body recognized as a leader in the airport world.
- "Integration testing": laboratory validation of the applications of 2 airlines in the CUPPS environment (in line with a situation in production). This phase involves checking that the applications have been correctly integrated into the platform without contravening RESA's integration and security constraints. RESA performed this phase with Lufthansa and Iberia airlines. Complementary tests were also carried out together with Continental and American Airlines.
- "Beta testing": validation in production of an airline's applications in the CUPPS environment on an airport platform. This phase consists of following check-in and boarding operations over a period of 5 days without making any changes to the platform or applications. RESA performed this phase with Lufthansa and Iberia at Brussels International Airport.

These phases were concluded with all involved parties signing documents attesting to the successful performance of the tests. These documents can be made available on request.
Find out more: CUPPS
 

IATA has created a set of documents which must be signed by the parties concerned (airlines and airport) during the different certification phases. RESA can provide these certification documents on request along with the contact details of the persons who took part in the certification.
 

Yes, the implementation of RESA's CUPPS was accompanied by a complete rewriting of the CREWS product which of course retains airline application compatibility with earlier versions of our CREWS CUTE system.
Airline applications which today are certified by RESA will therefore continue to operate on the CUPPS platform, thus giving airlines time to perform their upgrades.
The only constraint is certification of applications in Windows 7 for new installations.

 

This upgrade forms part of the ongoing maintenance of RESA products. It is therefore logical that the airport should migrate to this new major version of CREWS. This new system will enable the airport to continue operating current applications, install new CUPPS applications for airlines that request it and benefit from new administration tools supplied with this new version.
Nevertheless, the installation of the new system will require our technical team to carry out installation work and provide training in new administrative and supervision tools. This on-site work is charged to the airport.
 

RESA has developed tools which facilitate migration to the CREWS CUPPS system.
The first phase involves implementing CREWS CUPPS server modules and upgrading CREWS CUTE workstations with the latest versions (using RESA's centralized updating tools). Depending on the sites, this installation can be carried out during replacement of server equipment.
Once this phase has been carried out, migrating a workstation from the CREWS CUTE system to the CREWS CUPPS system takes place simply by logging on, thus ensuring a flexible and easy step-by-step migration.
There is no need to ask airlines for new connections or new addresses.
 

The CREWS CUPPS system must be installed on a server equipped with Windows 2008 Server R2 (64 bits with its own domain) and SQL2008 R2 licenses. For workstations, Windows XP or Windows 7 licenses (32 bits) are required in compliance with the IATA technical specifications.
Installing Windows 7 requires prior verification with the airlines in question to ensure that their application has been certified for this operating system.
 

Yes, additional training is required, as the platform's infrastructure is different to the CREWS CUTE system.
New maintenance tools have been created. They are based on RESA's new generic interfaces to facilitate configuration (Wizards have been added to facilitate basic administration tasks), information gathering and supervision on the installed base - to improve follow-up.
 

In theory yes, however this will require negotiations between the airline in question and the airport (provision of adequate network connections and equipment compliant with theoretical recommendations, etc.).
 

No, it specifies the general minimum operational characteristics (presence of a display, print speed, AEA version required, etc.), but not the detailed technical interface.
The only devices which can be operated on a CUPPS platform are those which fulfill the technical specifications and have been certified by RESA.
 

Yes, the Recommended Practice foresees the use of many devices such as automatic boarding gates or baggage scales (AEA 2009). If this equipment is CUPPS- or RESA-certified, it can be used in a standardized way by any application belonging to a CUPPS-certified airline, thus providing the airport with a sustainable and shared investment.
Many new peripheral devices are also planned. Their detailed definition is incorporated into the IATA specifications as and when concrete requests are made by airports or airlines (biometric devices, cameras, etc.).
 

With regard to CUPPS applications, the technical specifications impose new versions and minimum functions (workstations' power level, AEA 2008 or 2009 device program level).
Therefore, hardware upgrades should be expected; RESA will provide a hardware upgrade status to be provided for on a case-by-case basis.
 

Yes, in the same way as in CREWS CUTE mode today.
The technical specifications also guarantee shared, transparent use of scanners made available for CUPPS-certified applications (scanners such as MSR/OCR, etc. used on a shared workstation).
 

CREWS CUPPS enables airlines:
- to use their CUPPS applications;
- to more easily benefit from new devices (such as automatic boarding gates);
- to use the airport/host connection for sending IATA messages, thus saving on dedicated connections;
- to manage their users more freely (indeed, RESA provides tools which enable the airport to delegate to airlines the management of staff for accessing the CREWS system, etc.).

 

The CUPPS Recommended Practice does not define the protocol to be used between an application at the airport and the airline's host (even if, of course, airlines would more readily perform new upgrades on TCP-IP than on proprietary protocols such as P1024B or P1024C - also inaccurately referred to as ALC or UTS).

However, the Recommended Practice does define an additional exchange type which airlines can implement in their CUPPS application.

During CUPPS standard definition sessions, RESA put forward the need to allow airports to benefit from connections that are already set up with airlines for receiving IATA messages concerning flight management, thus ensuring the exchange of information without additional costs.

RESA's different products are certified with the CREWS CUPPS system:
- INFOPAX - RESA's Airport Information System (AODB) - for receiving MVT/PAL/CAL messages via the airline's CUPPS application;
- INVOICE - RESA's invoicing system - for receiving MVT/LDM/SLS messages via the airline's CUPPS application;
- BAGERA - RESA's baggage reconciliation system - for receiving or issuing BSM/BPM baggage messages via the airline's CUPPS application;
- etc.

Therefore, it is preferable for an airport equipped with various RESA products to ask airlines wishing to install their CUPPS applications to provide an "IATA"-type device during their implementation.
The definition of messages to be issued or received via this connection will form the subject of a contractual agreement with the airlines in question (as is already the case today, but often using SITATEX addresses).
The CUPPS Recommended Practice also includes an AIDX data exchange protocol between airlines' hosts and the airport's AODB. RESA's communication systems can be configured to take into account this type of data flow if an airline wishes to send them. RESA remains available to validate any implementations in this regard for its clients.
 

The rollout process currently used for packages of airlines certified in the CREWS CUTE environment will continue to apply in the immediate future.
However, IATA CUPPS work groups in which RESA actively participates, are currently working, together with the airlines, on defining a new "ARU" - Automatic Remote Update - device intended to facilitate remote rollout by airlines of minor versions of their applications without the airport's intervention.
This type of function enables airlines to improve management of their rollouts and it means that there is less maintenance for airports to perform where these updates are concerned. To improve follow-up, major updates are always performed by local teams in case of any problems (as is already the case today).
 

In general, the certification process is the same. It is simplified for airlines, as the first phase involving technical verification of the interface only needs to be carried out once.

Certification is carried out in several phases:
- a first "compliance testing" phase consists of performing test cases on one of the CUPPS-certified platforms;
- RESA is qualified as a "CTE - Compliance Testing Entity" for candidate airlines. This stage only needs to be carried out once for the airlines (as many times as there are suppliers today).
 

No, the technical specifications define a shared interface for accessing the platform's devices based on the exchange of XML messages on TCP-IP.
Any application provider is free to encode its application as it wishes. Only CUPPS-certified applications can be used on a CUPPS platform.
 

Yes, IATA work groups are working on integrating currently existing CUSS terminal functions into a future version of CUPPS using XML and TCP-IP technologies retained for CUPPS.
In the long term, the idea is to reduce airlines' investments in upgrades by offering them similar technical interfaces.
 

CREWS LDCS is sold to airports worldwide that make it available to the airlines and handling agents at their site. It is a computerized check-in and boarding system for processing passengers at check-in and at the gate. It is made available to any airline that doesn’t have its own DCS or doesn’t want to use its DCS at a site. It is specifically designed to meet the needs of handling agents, low-cost airlines and charters.
Find out more: CREWS LDCS
 

Yes, CREWS LDCS is fully integrated in the CREWS platform like any other airline DCS.
Find out more: CREWS LDCS
 

We offer various options for retrieving passenger lists. The PNL can either be sent directly by e-mail, imported via an Excel file provided by the airline, or retrieved as a standard PNL IATA message by an IATA TYPE B messaging service for example.
Find out more: CREWS LDCS
 

Yes, CREWS LDCS can interface with a BRTS. It can even handle transfer bags. At check-in, multiple destinations are automatically printed on the bag tag to optimize reconciliation through to the passenger’s final destination.
Find out more: CREWS LDCS
 

Yes, CREWS LDCS can print both ATB magnetic boarding passes and 1D and 2D barcode boarding passes, to meet new airline requirements. Of course, CREWS LDCS complies with the IATA’s “Simplifying the Business” initiative and can print and read 2D barcode boarding passes.
Find out more: CREWS LDCS
 

Yes, BAGERA handles all types of bags, including crew bags and oversize bags.
Find out more: BAGERA
 

Each bag is assigned a bag tag and a IATA message called BSM containing all the information about the bag. The bag tag barcode is scanned at the various handling zones (sorting, preparation, transfer, etc.) to accurately monitor the luggage handling process. All operations (loading, offloading, etc.) are recorded in the BAGERA system, which provides information in real time on the status and location of the bag. The bag and the passenger are “reconciled” when both are on board the aircraft.
Find out more: BAGERA
 

Bags travelling without passengers, also known as rush bags, are generally lost or delayed bags that are being re-routed. Rush bags are created in BAGERA either when a BSM message is received from the airline indicating “rush” status, or manually by the airline or handling agent who enters a bag tag number and assigns a destination from the flight destination list.
Find out more: BAGERA
 

There are two types of data that interface with the BAGERA system, namely flight information (Flight Information Management System) and bag information (airline hosts). To acquire the data, BAGERA can interface with many communication protocols (TCP/IP, e-mail, MQSERIES, MSMQUEUE, text tiles, BagMessage, Baglink, BAMS, etc.)
Find out more: BAGERA
 

BAGERA works with two types of scanners certified by RESA and recognized as the industry standard. These scanners enable baggage handlers to accurately and reliably perform baggage loading and reconciliation operations.
Find out more: BAGERA
 

Each user is identified by a log-in number. The administrator can see which users are logged in to a workstation or scanner at any time. The administrator can also update the BAGERA software version and control each scanner remotely.
Find out more: BAGERA
 

The alerts correspond to bag offloading operations. The alerts can be generated if a BSM message is received (BUM, Baggage Unload Message), if the characteristics of a ULD are changed or if a passenger disembarks. The users of the scanner handling the bag in questions receive an alert (red flashing LED), indicating that the bag requires priority handling. After verification, the bags are offloaded.
Find out more: BAGERA
 

The information can be displayed on the scanners in a number of different languages and is limited to the strict minimum required by the user. The system can create groups of users and assigns rights to each group. Each baggage handler can access information only about the flights he/she handles.
BAGERA is simple and user-friendly. All the information is presented on one screen (no multiple windows). The administrator can access the information using various search filters (per bag, per passenger, per flight, etc.), from his/her workstation and from any portable terminal (scanner/PDA).
Find out more: BAGERA
 

No, the CREWS CUTE system is not required to install PAXTRACK; it can be used with IATA 2D boarding documents only.
However, if the airport is equipped with CREWS, PAXTRACK can automatically collect information on passengers’ arrival at the check-in desks, baggage drop-off counters, boarding gates, etc., for improved tracking of passenger flow.
Find out more: PAXTRACK
 

No other RESA products are needed – PAXTRACK can operate completely independently at an airport where airlines use IATA 2D bar codes, regardless of the check-in and boarding system used by the airlines.
However, PAXTRACK can be interfaced with other systems used at the airport, such as the Airport Operational Database for information on flights and resources, the baggage sorting or reconciliation system, or a native baggage message system (BagMessage, BAMS, etc.) to collect passenger baggage information, etc.
Find out more: PAXTRACK
 

Yes, PAXTRACK can take into consideration various criteria defined with the airlines, based on all the information contained in the bar code identifying the passenger (for example, business or frequent passengers, those traveling to certain destinations, etc.). This service can be sold by the airport to its airlines. The highly flexible system enables the airport to define a series of rules using a user-friendly interface similar to that used for displaying images in the VISTA flight information display system. PAXTRACK can be used in conjunction with VISTA to display information to guide passengers to the priority queues.
Find out more: PAXTRACK
 

PAXTRACK is compatible with all boarding documents containing 2D bar codes that comply with IATA resolution 792, regardless of the media used: traditional boarding passes, mobile phone boarding passes, boarding passes printed from the Web, etc.
PAXTRACK can also be interfaced with the airport’s local CRM-type systems, allowing it to recognize even 1D passenger identification bar codes.
Find out more: PAXTRACK
 

The airport can establish fixed scan points (self-service kiosks used by the passenger or by an agent) or can provide its agents with mobile terminals (scanners) so that they can move freely within the airport and check the validity of transport documents, make sure that passengers are in the right place and guarantee passenger traceability. For this equipment to operate with the PAXTRACK system, it must first be certified by RESA. PAXTRACK can also be installed on passenger information kiosks or automatic gate systems (passenger filters, lounge entrances, passes, self-boarding, etc.).
Find out more: PAXTRACK
 

RESA provides tools to generate graphs using the data collected. However, the airport must consult all the airlines operating at the airport to secure their agreement and establish the scope for the use of these data (duration of use, agreement not to keep a record of passenger names, etc.). The format of the consultable data is supplied by RESA if the airport wishes to incorporate them directly into its statistics management tool.
Find out more: PAXTRACK
 

Yes. The airport simply needs to install a scan point at the entrance to the lounge. The PAXLOUNGE ACCESS external module provides agents with passenger data (available on the boarding passes) so that they can authorize access to the lounge. The rules of entry can be set in accordance with the contracts concluded with the different airlines.
Find out more: PAXTRACK
 

Yes. The management rules included in the PAXTRACK administration tool enable the airport to define a wide range of different checks that can be operated when a boarding pass is scanned, including a passenger uniqueness check, and also checks as to whether the passenger is suitably located to board the flight, the flight time, the passenger class, etc.
Find out more: PAXTRACK
 

Yes. The MISSING PAX external module, a module for monitoring passengers at CREWS boarding gates, enables airlines to consult information on the passengers for their flights. This tool can provide the airline with a list of passengers “seen” at the airport, which is particularly important if there are passengers without baggage who have checked in outside the airport (connections, Web check-in, return journey within a day, etc.). The system provides comprehensive monitoring information; the precision of this information depends on the number of scan points set up by the airport. A scan point at the entrance or exit to the screening station, for example, can inform the airline of whether the passengers are in the boarding area, helping them to identify latecomers.
Find out more: PAXTRACK
 

RESA-certified mobile scanners support WIFI protocols 802.11 a, b and g. Depending on the model, they can also support other protocols to meet specific airport requirements (GPRS, for example).
Find out more: PAXTRACK
 

Yes, the same mobile scanners can be used for the BAGERA baggage reconciliation system and the PAXTRACK system. This simplifies the management of the stock of spare equipment and means that different teams can share the equipment if necessary. One scanner can also host both applications simultaneously if required.
Find out more: PAXTRACK
 

Yes, if an external system sends the information to PAXTRACK. The application can interface with a baggage sorting system, a baggage reconciliation system or a direct line such as SITATEX with airlines, BagMessage and CREWS BAMS for the receipt of BSM messages.
Find out more: PAXTRACK
 

Yes, the technical architecture of PAXTRACK is compliant with the other products in the RESA range. It is entirely possible to install it on servers already used to host other RESA products. All that is needed is enough disk space for the recorded tracking information.
Find out more: PAXTRACK
 

Yes, PAXTRACK can identify the number of passengers per flight. For airports fitted with CREWS, PAXTRACK can provide precise graphs representing passenger arrival at check-in desks and can calculate passenger types (out of the total number of passengers on board, how many went through the check-in desk or the baggage drop-off counter, how many did not use the airport facilities, how long before the flight did the passengers arrive at check-in depending on flight type, etc.).
Find out more: PAXTRACK
 

Yes, the WAITING TIME external module is available to feed the airport’s VISTA flight information display system. This tool sends information to the FIDS on the average movement times between fixed scan points.
Find out more: PAXTRACK
 

PAXTRACK can collect information from various scan points and can interface with any CRM, car park or airport shop management system, etc. Passenger scan details are collected by the airport, which can use these data and send messages to the various external systems involved. RESA is available to help airports analyze the potential integration of different systems.
Find out more: PAXTRACK
 

No. The more scan points there are, the more the sources of information, and therefore the more comprehensive the statistics that can be provided.
Find out more: PAXTRACK
 

The three modules can be installed on the same computer. However, system performance will depend on the computer’s speed and memory capacity.
Find out more: INFOPAX
 

The FAIRWAY communication gateway ensures data sharing among the various systems that connect to the INFOPAX FIMS (civil aviation, radar, baggage sorting, noise system, billing, public display, etc.). The exchanges can be bidirectional (data sent by the FIMS to external systems and data received by the FIMS from external systems). FAIRWAY formats the data and translates the protocols.
Find out more: INFOPAX
 

No, the license is a site license. The price is based on the traffic at the airport and not the number of users.
Find out more: INFOPAX
 

DIAGRAM, an additional INFOPAX module, manages the resources necessary to operate a flight (check-in counters, gates, baggage chutes, exits, baggage carrousels, parking stands). DIAGRAM reads and updates INFOPAX data. Everything done via DIAGRAM automatically updates the data in INFOPAX.
Find out more: INFOPAX
 

We have developed VISTA, a proprietary Flight Information Display System that displays flight information to the public. However, INFOPAX can support any other display system. Simply configure the INFOPAX/Display Server communication protocol to comply with the display server’s interface specifications.
Find out more: INFOPAX
 

For any given day (usually the next day) the INFOPAX administrator can display and print a report containing the flight list in chronological order and linked by rotation.
Find out more: INFOPAX
 

Once completed, the flights in the real time program are archived. This can be used later for statistical and billing purposes. A parameter can be set to specify how long the flights will be accessible by the user before they are archived.
Find out more: INFOPAX
 

DIAGRAM graphically manages the physical resources defined in the Flight Information Management System INFOPAX, namely: check-in counters, boarding gates, baggage chutes, exits, baggage carrousels, and parking stands.
Find out more: DIAGRAM
 

DIAGRAM can be used in real time or in planning mode for provisional allocation of resources with the possibility of modifying the information in real time.
Find out more: DIAGRAM
 

DIAGRAM is a totally secure system. Consistency checks are automatically performed whenever resources are allocated or modified. The user is alerted if there is an input error, if for example he/she assigns more than one flight to the same parking stand at any given time, or if the aircraft size is not compatible with the size of the parking stand.
Find out more: DIAGRAM
 

DIAGRAM receives information from the INFOPAX Flight Information Management System. The flight data are updated with the INFOPAX database. Any changes in INFOPAX are updated in real time in DIAGRAM and vice versa.
Find out more: DIAGRAM
 

DIAGRAM’s information management tool can define scenarios containing text, logos, videos, etc. Advertising and special alert messages (strike for example) can be alternated with the primary images (departures list).
Find out more: VISTA
 

The user management tool is used to create groups of users. VISTA assigns access rights to each group.
Find out more: VISTA
 

VISTA’s fleet supervision and management tool shows all the display terminals (online / offline status) as well as all the images displayed.
Find out more: VISTA
 

The VISTA server and display terminals are connected to the standard Ethernet network. The protocol used is TCP/IP.
Find out more: VISTA
 

VISTA can be used in degraded mode. The tool VISTA DATA continues to display information if the FIMS is unavailable.
Find out more: VISTA
 

The terminals must have internal software enabling VISTA to dialog and exchange the data needed to create the images. The exchange protocol is TVI.
Find out more: VISTA
 

The image editor allows users to create new images, test them locally and assign them to display terminals.
Find out more: VISTA
 

Agent tools on the workstations dialog directly with the VISTA system to control the display (opening, closing, boarding groups, class, etc.).
VISTA then sends the information to the FIMS to ensure that both systems have the same data.
Find out more: VISTA
 

VISTA WEB uses the airport’s intranet to display flight information on standard computers via Internet Explorer.
Find out more: VISTA WEB
 

Simply declare the new terminals (IP addresses) in the fleet supervision and management tool. The display administration tool sends the images to the terminals and implements display rules.
Find out more: VISTA
 

VISTA has translation tables to easily convert messages into the desired language by selecting a different translation column. The tables can be easily modified using an editing tool provided with the mask editor.
Find out more: VISTA
 

Yes, the two systems receive information in real time from the Flight Information Management System totally independently.
Find out more: VISTA WEB
 

VISTA WEB uses the standard network and displays flight information on any computer running Internet Explorer.
Find out more: VISTA WEB
 

VISTA WEB images are in table form. The administration tool can be used to change the table headings and content for a group of users.
Find out more: VISTA WEB
 

The “scheduled flights” tool shows future flights for the day selected. With the standard settings, flights can be viewed up to 100 days in advance. Search filters allow searches by airline, stopover, codeshare companies, handling agents, etc.).
Find out more: VISTA WEB
 

The “Airport Life” module can be used to create service message such as maintenance, weather, alerts, etc. These messages are time-limited and are displayed on all staff workstations.
Find out more: VISTA WEB
 

INVOICE can interface with any Flight Information Management System. It just needs to receive the flight information from the FIMS. In this case, it comes with the reference database.
INVOICE can also operate without a FIMS, since it does not require upstream flight information. All the flights will have to be entered into the INVOICE flight management interface.
Find out more: INVOICE
 

INVOICE has a manual billing module that can be used to bill for any type of product or service as long as it has been assigned to a General Accounting Plan account and follows the equation: Quantity X Unit Price = Price.
Find out more: INVOICE
 

INVOICE interfaces with CASTOR, the flight traffic and load data collection system, which automatically processes messages from the airlines and links traffic data to flights. This interface significantly improves billing automation and productivity.
INVOICE can also receive flight data from the General Directorate of Civil Aviation and send back the processed flights.
Find out more: INVOICE
 

Depending on the file format provided by the airport, INVOICE interfaces with all standard accounting systems on the market (Lineal, Adonix, etc.). It links each billed service to accounting data such as the account number, VAT number, etc. and authorizes the transfer of entries to the airport’s accounting system.
Find out more: INVOICE
 

The two systems share their reference databases (airlines, stopovers, registrations, etc.). The databases are added according to the needs of each application. The two systems work with absolutely the same data.
Find out more: INVOICE
 

INVOICE can handle multiple currencies. All the currencies are listed in the currency table and a conversion rate is defined for each currency with respect to the reference currency.
Find out more: INVOICE
 

The “Draft” feature is used to check the invoices and attachments before issuing. Draft invoices can be sent to the airlines for validation. They can be cancelled if necessary or converted into definitive invoices. Draft invoices can be saved in PDF format and sent by email. Comments can also be entered and will appear on the definitive invoice.
Find out more: INVOICE
 

INVOICE can reprint any archived invoice from the list of archives. Generally speaking, invoices can be sent out in various formats. They can be printed, saved in PDF format, and sent by email.
Find out more: INVOICE
 

An optional interface can link plans and data from the database for visual management to assist in decision making using themes and bubbles. The airport maps provide all the information users need. They can access building data from the map or view the map based on building data.
Find out more: ATLAS
 

A mobile application provides inventory management on a Tablet PC. The database is updated with the new data upon return to the client/server environment.
Find out more: ATLAS
 

ATLAS ensures continuity with the airport’s accounting system. It interfaces with all standard accounting systems on the market (Lineal, Adonix, etc.) eliminating the need to enter information twice.
Find out more: ATLAS
 

Rentals and services are billed in advance based on an agreement. Changes or termination of the contract before the end of the billing period will automatically generate an adjusted invoice / credit note. For example, if a tenant vacates during the billing period, ATLAS will automatically generate a prorated credit note. Likewise, the system will generate an additional invoice if a tenant increases the amount of space rented during the period.
Find out more: ATLAS
 

The “Draft” feature allows users to check the invoices before issuing. They can be cancelled if necessary or converted into definitive invoices. They can also be sent by e-mail to the customer for validation, which reduces the number of contested invoices.
Find out more: ATLAS
 

ATLAS has a manual billing mode that can be used to create single billable items, such a bottle of champagne. It can generate single invoices as needed. This module can also be used to generate credit notes manually.
Find out more: ATLAS
 

ATLAS has an alert system that automatically sends an e-mail to a pre-defined mailing list. For example, for agreements expiring in 2 months, an e-mail is sent to the sales department to request renegotiation or termination of the agreement. Alerts can be created for specific events, along with the corresponding mailing lists.
Find out more: ATLAS
 

CASTOR collects and decodes flight data in real time (IATA MVT Message: estimated arrival time, estimated departure time, delay) and deferred mode (IATA LDM message, load per stopover, passenger type, freight, post, etc.).
Find out more: CASTOR
 

Each airline operating at the airport has to send IATA messages to CASTOR for it to work properly. Typically, these messages are sent to a SITATEX address at the airport, connected via TCP/IP Type B or via SDK Daemon SITA, which corresponds to SITA placing the messages in IN and OUT directories. It is also possible to use an AVINET link by ARINC. This solution provides a SITATEX address and converts the messages received into an e-mail. The message is configured at Avinet’s website at the discretion of the airport. RESA’s FAIRWAY communication system can also receive any type of IATA messages at an e-mail address.
Find out more: CASTOR
 

Yes. For example at the Paris airport (CDG) CASTOR can interface with all the Flight Information Management Systems. It just needs to receive the flight information from the airport’s FIMS. It can then link the messages received to the flights and send the completed information back to the FIMS.
Find out more: CASTOR
 

Deferred CASTOR comes with a validation tool that handling agents can use to check the validity of the linked data and modify them if necessary. Any modifications are provided to the airport. Validated data are sent to the airport for integration and billing, which greatly reduces the number of contested invoices.
Find out more: CASTOR
 

CASTOR transfers flight data from the airport (actual linked data) automatically. There is no copying off a Telex print-out and no manual input. Airport staff doesn’t have to spend time entering data. CASTOR also provides highly reliable airport statistics.
Find out more: CASTOR
 

CASTOR can interface with any airport billing system. It just needs to receive the flight information from the airport’s FIMS. It can then link the messages received to the flights and send the completed information back to the airport billing system.
Find out more: CASTOR
 

Completed and validated traffic data can be sent back to the declarers and airlines so they can check their statistics and invoices. To send data to an external system, additional FAIRWAY modules can be integrated into the CASTOR system to convert any protocols as necessary.
Find out more: CASTOR
 

FAIRWAY is the heart of the communication system. It can receive data from various external systems and make them available to the Flight Information Management System (FIMS) using whatever protocol is necessary (IP messages, local file, FTP file transfer, SQL insertion in a database table, etc.).
Find out more: FAIRWAY
 

FAIRWAY is a central platform that transmits all data to and from external systems (civil aviation, airlines, etc.). It also sends data to all the information systems connected to the airport such as voice servers, display systems, billing, baggage sorting and noise systems, etc. Its role is to facilitate data sharing and seamlessly handle the protocols needed for all the systems to communicate with each other.
Find out more: FAIRWAY
 

FAIRWAY periodically generates a file containing the projected flight information and a file containing real time flight information updated frequently (RESA UCCEGA standard protocol). These files are sent by FTP to the airport’s internet server using the FAIRPACK Internet module. The airport website application can easily process the files and display the information.
Find out more: FAIRWAY
 

During migration, FAIRWAY modifies the architecture of the Flight Information Management System gradually to ensure safe migration without affecting system availability. It processes message formats dynamically so it can integrate a new service by creating a new message. The new service is tested while the old service is still in place. It is easy to return to a prior stable operating status if necessary.
Find out more: FAIRWAY
 

FAIRWAY has a TCP/IP protocol and standard message formats for flights and resources for example. We can also develop any type of interface needed upon request, based on airport specifications.
Find out more: FAIRWAY
 

The main function of FAIRWAY is message routing and multiplexing. It can receive messages via TCP/IP from one or more senders and send messages back to one or more recipients.
Find out more: FAIRWAY