The current turnaround process involves many different entities performing many different operations and letting much inefficiency to arise. This may be attributed to lacking common situational awareness; inadequate information sharing and fragmented data flows. As a result readjustment of aircraft’s target off-block time is often unavoidable. By improving common situational awareness at the airport level, delay propagation from one turnaround sub-process to another or even to the turnaround process of another aircraft can be solved timely.
The TITAN concept addresses turnaround delay causes by recognizing that the turnaround process, which includes relevant landside processes too, is an integral part of the aircraft’s business trajectory. Such delays may arise from:
– poor information sharing;
– planning deviation;
– demanding security processes.
The TITAN concept takes advantage of Collaborative Decision Making (CDM) and System Wide Information Management (SWIM) concepts to combine information from multiple sources. In this way communication between turnaround stakeholders is getting improved enabling them to improve their own planning and execution by knowing when relevant milestones have been met. The TITAN tool is expected to be installed in an airport where CDM is already implemented; by connecting it to CDM systems it receives messages as input and sends messages when appropriate.
The key points to be captured by the tool are:
-Improved situational awareness – all stakeholders have improved access to data about the turnaround process allowing better decision making;
-Highlighting when issues occur – when an issue impacting (or potentially impacting) the turnaround process occurs, affected stakeholders are informed;
-Problems in the turnaround can be solved in a timely manner and reduce overall aircraft delays due to turnaround issues.
As a start, TITAN develops a decision-support tool for an airline to better evaluate and negotiate changes in the turnaround of its aircraft. However, this does not mean that a future production system should only target airlines as potential customers but any partner involved in the turnaround.
The vision is that the users will see TITAN as one or more web pages that they can interact with. Behind the scenes, server components will take care of data persistence, message handling etc. By using a web-application approach most users should be able to use TITAN on their existing hardware and it remains possible to implement dedicated applications for differing platforms (i.e. mobile devices). By selecting the right technologies, the system is available to the widest possible audience.
The tool is usable by stakeholders simply by logging into it at a publically available website. It supports different actors by providing them with duty-related information.
The TITAN tool implements two main displays: a table of relevant data i.e. a list of all arriving flights; and a timeline overview of a single aircraft turnaround. Displays are expected to be interactive instead of static HTML pages; i.e. clicking on a flight in the table of all arrivals will open the timeline for that flight’s turnaround process.
The TITAN tool architecture is reasonably simple (Figure 1). At the backend there is the TITAN information sharing (TIS) platform, which is a large data-store containing TITAN specific information and information coming from other CDM systems. Most important, it contains the data from the various process services, i.e. the passenger flow information service. Each one of these services has the ability to read and write to TIS, and they can all communicate with each other. The users access TITAN via web-based clients. These are either thin clients running inside a user’s existing browser or thicker clients exclusively produced for TITAN. Both communicate with the server-side applications for data. A common messaging hub is used for the communication between processes on the server-side. In order for the clients to contact the services, a set of standardised end points i.e. URLs are defined. Third party systems may change data in TIS via CDM or other stakeholder systems. TIS may subscribe to an external system to receive updates.
To get access to the GUI displays the user must follow the following procedure:
1. User types the TITAN address or uses a bookmark to load the TITAN tool into his browser.
2. TITAN determines if the user has an active session; if yes, last session’s state is displayed; if no, a login screen is served up for display on the client.
3. User types his username and password into the login screen.
4. TITAN client transfers login details to server side for validation.
5. TITAN validates the username and password against a collection of valid users; if yes, the user’s default screen is generated, served and displayed on the client; if no, an error message is shown.
6. After successful login, a session is started so that the user can navigate to other TITAN pages without needing to login to each one.
I.e. for the “list of flights” display, TITAN queries the TIS database to get the list of all flights arriving at the airport and builds a page displaying them all, which is served for display in the client.
The user clients render data obtained from the TITAN server in two ways:
-Direct request – client requests information and expects a response;
-Subscription – client subscribes for data and expects asynchronous notifications on relevant data changes.
Users logs into the client and the client connects to all services it relies upon. Thus, the user does not need individual knowledge of all the backend services. On the other hand, the TITAN server-side
-accepts and records subscription requests;
-monitors data associated with subscriptions;
-sends messages to subscribed clients upon data changes;
-accepts and responds to direct requests for data.
Since different stakeholders require different views the TITAN tool will implement a common client interface with a certain level of customizability. To overcome the drawbacks of client-side storage of user settings, server-side view preference storage is chosen.
Since TITAN is not intended to be used for issuing commands, there is no way to initiate changes to time estimates, i.e. EOBT, through its interface. This is considered to be done by traditional means of communication. As the changes spread through the system, the involved TITAN services get notified and changes are reflected on the GUI.
All GUI pages will be based on the following principles:
-The user logs in and his username is displayed on the screen. The user can log out by hitting the corresponding tab.
-Local time is displayed permanently.
-For thick clients, all interacting UI elements are properly sized to enable touch optimization.
-Federated log-in enables redirection to previously saved session states.
-Whenever any kind of data that is displayed on the current view changes, the particular portion of the page that contains the data is automatically refreshed with the new data.
The TITAN tool clients will have the following three displays.
Summary view
The summary view screen of the client is basically a table with one row representing a flight pair (Figure 2). The table will have fixed columns replaceable by the user. The default client display will obey to the following principles:
-Common flight information columns, incl. status, flight number, from/to designators, EI/OBT, will be fixed and all others replaceable.
-TITAN colour coding will be used in close relation to the flight information columns (i.e. coloured frame).
-Unnecessary columns can be replaced by a list of available columns. Changes in layout for the particular user will be registered server-side enabling redirection to last saved layout when logging in from a different client.
-A detailed view of a particular flight pair comes up by clicking to the fixed column.
Details View
The details display of the client consists of 4 parts (Figure 3):
-Flight pair strip which is an exact representation of the fixed columns of the summary view table;
-Clickable tabs area with tabs representing turnaround milestones with active textual content;
-Rows of customizable data, where user-preferred rows can be selected and different data can be set for all tabs;
-Process details view section with content according to the selected tab.
The details display of the client will obey to the following principles:
-Agreed TITAN colour coding of the summary view will be used on the tabs bar and in Gantt views of different tab panels too.
-Agreed customizability of summary view data columns will be used also for data rows of the details view (selection from a customisable row list and storage of last used layout).
-Summary view (with the actually closed flight in focus) can be recalled by clicking on either the flight pair strip or back button.
-Tab bar consists of tabs with active content related to the agreed TITAN colour coding. All tabs must be able to indicate the following common messages:
• “normal operation” (0 information level in Green); or
• “not applicable” (in Gray); or
• a short user-defined “status message”; or
• The highest-level information related to the specific flight and the specific sub-process, or “n issues” text (number of information of the same highest level).
Process Details View
The process details section (Figure 3) shows detailed information about the progress of a selected process providing the most relevant information for common situation awareness and collaborative decision-support. If the user has write access, supporting information can be submitted in the tab details section.
In case of delays, the selected tab is coloured red according to TITAN colour coding, and the information level is upgraded to level 3. In this situation, the client identifies all affected flights. If there is connecting business passengers on board of the delayed arriving flight, scheduled EOBT’s of the connecting flights are coloured correspondingly in the Gantt diagram. A yellow colour corresponds to information level 3 indicating need for immediate action in case that the connecting flight has to wait for the arriving passengers to be on-time.
The process details display provides information about the following processes grouped in tabs:
-General information;
-Check-in;
-Passenger security control;
-Baggage (un)loading;
-(De)boarding tab;
-Services (catering, cleaning, power supply);
-Fuelling;
-Start-up;
-De-icing.
The minimum information content of process details section tabs include:
-Stand/gate allocation;
-Gantt of affected flights;
-First/last passenger/baggage, passenger/baggage number/list;
-Problem notification;
-Open/close or start/end times as well as milestone completion times.
Accessing TIS through TITAN tool GUI and feeding it with actual information enables users to share a common situational awareness of the progress of the turnaround processes they are involved in and their actions have an impact on. In this way, TITAN promises a more efficient and more predictable progressing of the aircraft turnaround.
Although TITAN project is still in progress and planned to be completed by the end of this year, there is no doubt about the following fact; with improved management of existing infrastructure resources being the only sustainable solution left for world’s largest hubs suffering from delay problems and continuous demand increase, increasing the efficiency and predictability of aircraft turnaround can be nothing less than promising.
To read more, click here.