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.

Figure 1. Tool architecture

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

Figure 2. Example of GUI 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

Figure 3. Example of GUI 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.

Lindbergh in paris

Here is a video recording the events around this historic feat.

The timeline of the flight went like this:

7:52am – Charles Lindbergh takes off from Roosevelt Field, Long Island, New York. The heavy plane, loaded with 450 gallons of fuel, clears telephone wires at the end of the runway by only 20 feet.
8:52am – Altitude: 500 ft. Wind velocity: 0 mph. Currently over Rhode Island. Except for some turbulence, the flight over Long Island Sound and Connecticut was uneventful. Only 3,500 miles to Paris.
9:52am – Boston lies behind the plane; Cape Cod is to the right. Altitude: 150 ft. Airspeed: 107 mph. Wind velocity: 0 mph.

10:52am – There’s a breeze blowing from the NW at 10mph. Lindbergh begins to feel tired, although only four hours have passed since leaving New York. He descends and flies within ten feet of the water to help keep his mind clear.
11:52am – Four hundred miles from New York. Altitude: 200 ft. Nova Scotia appears ahead. After flying over the Gulf of Maine, the Spirit of St. Louis is only six miles, or 2 degrees, off course.
12:52pm – Wind velocity has increased to 30 mph. Lindbergh flies over a mountain range. Clouds soon appear and thicken as the Spirit of St. Louis approaches a storm front.
2:52pm – Altitude: 600 ft. Air speed: 96 mph. Lindbergh’s course takes him away from the edge of the storm. Wind velocity has dropped to 15 mph.
3:52pm – The eastern edge of Nova Scotia’s Cape Breton Island lies below. In minutes Lindbergh will be over water again. Although it’s only the afternoon of the first day, Lindbergh struggles to stay awake.
5:52pm – Flying along the southern coast of Newfoundland. Altitude: 300 ft. Air speed: 92 mph. Wind velocity: 20 mph.
7:52pm – Stars begin to appear in the sky as night falls. The sea below is completely obscured by fog. Lindbergh climbs from an altitude of 800 ft to 7500 ft to stay above the quickly-rising cloud.
8:52pm – Altitude: 10,000 ft. The cloud that first appeared as fog is still below. A thunderhead looms ahead. Lindbergh files into the towering cloud, then turns back after noticing ice forming on the plane.
10:52pm – Lindbergh’s fight to keep his eyelids open continues. To keep warm, Lindbergh considers closing the plane’s windows, but then decides that he needs the cold, fresh air to help stay awake.
11:52pm – Altitude: 10,000 ft. Air speed: 90 mph. Five hundred miles from Newfoundland. The air has warmed — there’s no ice remaining on the plane.
1:52am – Halfway to Paris. Eighteen hours into the flight. Instead of feeling as though he should celebrate (as he had planned), Lindbergh feels only dread: eighteen long hours to go.
2:52am – Daylight! Because Lindbergh has travelled through several time zones, dawn comes earlier. The light revives the pilot for a while, but then drowsiness returns. He even falls asleep, but only for a moment.
4:52am – Flying in the fog. Lindbergh continually falls asleep with his eyes open, then awakens seconds, possibly minutes, later. The pilot also begins to hallucinate. Finally, after flying for hours in or above the fog, the skies begin to clear.
7:52am – Twenty-four hours have elapsed since taking off from New York. Lindbergh does not feel as tired.
9:52am – Several small fishing boats spotted. Lindbergh circles and flies by closely, hoping to yell for directions, but no fishermen appear on the boats’ decks.
10:52am – Local time: 3:00pm. Lindbergh spots land to his left and veers toward it. Refering to his charts, he identifies the land to be the southern tip of Ireland. The Spirit of St. Louis is 2.5 hours ahead of schedule and less than three miles off course.
12:52pm – Wanting to reach the French coast in daylight, Lindbergh increases air speed to 110 mph. The English coast appears ahead. The pilot is now wide awake.
2:52pm – The sun sets as the Spirit of St. Louis flies over the coastal French town of Cherbourg. Only two hundred miles to Paris.
5:22pm – The Spirit of St. Louis touches down at the Le Bourget Aerodrome, Paris, France. Local time: 10:22pm. Total flight time: 33 hours, 30 minutes, 29.8 seconds. Charles Lindbergh had not slept in 55 hours.

(Source: The Spirit of St. Louis, by Charles A. Lindbergh, Lindbergh site)

ICAO Aviation System Block Upgrades

Although air traffic demand is not growing evenely everywhere, almost no part of the world is without some kind of air traffic management modernization project. In terms of overall cutting edge concepts and technology plans, the US, Europe and Japan are the undisputed leaders. At the same time, other regions like Latin-America and Asia-Pacific have shown leadership in the early application of advanced solutions like PBN.

While in the past ATM improvements were based on an infrastructure that was standardized world-wide (like VOR/DME or ILS) some of the new concepts are predicated on infrastructure improvements and new aircraft equipment that sometimes exist in different flavors and not all are necessarily compatible.

Adoption of different flavor solutions in different parts of the world raise the specter of a loss of interoperability, a situation that is extremely costly for the airspace users to remedy or to accommodate.

Even perfectly interoperable solutions, if implemented with no or little coordination in different parts of the world, can lead to mandates that can only be met with difficulty and excessive cost that is otherwise avoidable if a more structured approach is used.

In the past, the International Civil Aviation Organization’s (ICAO) reputation has suffered somewhat as a result of the extremely bureaucratic way it approached everything and the glacial paced decision making this entailed. At the same time, ICAO continued to be the only world-wide body which was empowered to say the last word on most of aviations air traffic management related provisions and hence there was no way of going around this mostly benign, but sometimes still belligerent giant. Regions keen on improving their ATM environment tried hard to progress even while ICAO lagged and this was leading to a situation where, in spite of its importance, in some aspects ICAO was becoming irrelevant.

But no more! Under new management at the top and mindful of the economic crisis affecting the air transport industry, ICAO has transformed itself into a cost-conscious, business oriented organization that does make a genuine effort to help ATM evolution along.

The first product was the ICAO Global Air Traffic Management Operational Concept (ICAO Doc 9854) which was significant because, for the first time, it actually formalized even concepts like the transfer of separation responsibility to the cockpit. By the way, most of what you find in Doc 9854 was first written up in the context of the European ATM modernization project ATM2000+.

Of course an operational concept as such is of little value until you define how the concept will be implemented and describe the changes in the ATM infrastructure that need to be realized for the concept to work.

The best known such projects are the NextGen Air Transportation System (NextGen) in the US, the Single European Sky ATM Research (SESAR) in Europe and the Collaborative Actions for Renovations of Air Traffic Systems (CARATS) in Japan.

Although there is some co-ordination between these projects and NextGen and SESAR are particularly keen on ensuring interoperability, there was no real, world-wide guidance on how to modernize an ATM system, whether in a single country or a region. With air traffic demand growing in leaps and bounds everywhere, the need for modernization was popping up in different countries and ICAO very correctly felt that not all of them would be up to the task of completing the projects in a safe and cost efficient manner.

To help with these highly complex tasks and to avoid repeating mistakes, it was decided that the experience available from NextGen, SESAR, CARAT as well as other, smaller projects should be shared for the benefit of the industry as a whole, everywhere in the world.

Of course it was also recognized that a one-size-fits-all approach would never work in the world-wide context and therefore the guidance had to take a form that would be useable and useful everywhere with clearly not every part of it being applicable in all cases and all locations.

The result was the ASBU or Aviation System Block Upgrades. ASBU comprises a suite of modules, each with the following essential characteristics:

• A clearly-defined measurable operational improvement and success metric;
• Necessary equipment and/or systems in aircraft and on ground along with an operational approval or certification plan;
• Standards and procedures for both airborne and ground systems; and
• A positive business case over a clearly defined period of time.

The modules are composed of flexible and scalable building blocks that can be implemented in a given country or a given region to meet identified needs and depending on the readiness of the given environment. Mindful of the fact that not all modules are required in all areas, the arrangement is such that it is possible to leave out certain modules so that the actual implementation can be customized for the prevailing circumstances. Modules can always be added later.

The Block Upgrades describe a way to apply the concepts defined in the ICAO Global Air Navigation Plan (Doc 9750) with the goal of implementing regional performance improvements. They will include the development of technology roadmaps, to ensure that standards are mature and to facilitate synchronized implementation between air and ground systems and between regions. The ultimate goal is to achieve global interoperability. Safety demands this level of interoperability and harmonization. Safety must be achieved at a reasonable cost with commensurate benefits.

Leveraging upon existing technologies, block upgrades are organized in five-year time increments starting in 2013 through 2028 and beyond. Such a structured approach provides a basis for sound investment strategies and will generate commitment from equipment manufacturers, States and operators/service providers. The block upgrades initiative will be formalized at the Twelfth Air Navigation Conference, in November 2012.

The development of block upgrades will be realized by the change of focus from top-down planning to more bottom-up and pragmatic implementation actions in the regions. The block upgrades initiative is an instrument that will influence ICAO’s work program in the coming years, specifically in the area of standards development and associated performance improvements.

But what exactly are these blocks and modules?

A MODULE is a deployable package representing some kind of performance or capability. Such a module will bring a defined performance benefit which is traceable to a change in operations and which is based on defined procedures, technology, regulations, standards and a business case. Each module will also be applicable only in a given operating environment. The modules will be created in a way that will make them suitable for being combined to fit the actual requirements without the need to implement elements that are not necessary.

A THREAD is a series of dependent modules across the block upgrades representing a coherent transition in time from basic to more advanced capability and associated performance. The date considered for allocating a module to a block is that of the Initial Operating Capability (IOC). A thread describes the evolution of a given capability through the successive block upgrades, from basic to more advanced capability and associated performance, while representing key aspects of the global ATM concept.

A BLOCK is made up of modules that when combined enable significant improvements and provide access to benefits. The notion of blocks introduces a form of quantization of the dates in five year intervals. However, detailed descriptions will allow the setting of more accurate implementation dates, often not at the exact reference date of a block upgrade. The purpose is not to indicate when a module implementation must be completed, unless dependencies among modules logically suggest such a completion date.

What is the Performance Improvement Area (PIA)? Sets of modules in each Block are grouped to provide operational and performance objectives in relation to the environment to which they apply, thus forming an executive view of the intended evolution. The PIAs facilitate comparison of ongoing programs.

The four Performance Improvement Areas are as follows:

1. Greener Airports

2. Globally Interoperable Systems and Data – through Globally Interoperable System-WideInformation Management

3. Optimum Capacity and Flexible Flights – through Global Collaborative ATM

4. Efficient Flight Path – through Trajectory Based Operations

Figure 1. Blocks, modules and performance areas

You will notice that each block includes a target date. This is meant to be the Initial Operating Capability (IOC). At the time of creating the ASBU, blocks 0 and 1 were the most mature and blocks 1 and 2 are supposed to have sufficient substance to ensure that the vision for the future can properly drive the early implementation activity.

Each of the Modules that form the Blocks must meet a readiness review that includes the availability of standards (to include performance standards, approvals, advisory/guidance documents, etc.), avionics, infrastructure, ground  automation and other enabling capabilities.

Figure 2. Blocks and their timing

An interesting and novel requirement against the modules is that in order to qualify for inclusion, each must have been implemented in at least two regions and must have all the necessary operational approvals and procedures in place. This ensures that later implementers can always draw on the experience of the pioneers.

The following figure shows the improvements expected from Block 0. While this is an impressive set of benefit sources, it also shows that States have not been doing their homework properly in the past ten to 15 years. Information management or en-route digital link has been on the table for a long long time and ASBU now introduces them with an IOC of 2013…

Figure 3.This is what Block 0 will bring

Anyway, ASBU is a good initiative because it does bring together the varied elements of ATM modernization activities from all over the world on the one hand and provides a wealth of shared experience to everyone involved on the other.

The 12th. Air Navigation Conference later this year will be discussing the ASBU and is expected to formulate the necessary decisions that will formalize the global co-ordinated deployment of block upgrades.

Of course, the ASBU is no silver bullet. It is a good framework, sound guidance and a depository of shared implementation experience that will help, but not substitute, good and sound planning on the local and regional levels. Perhaps the most important contribution of the ASBU is the way it highlights the global intertwining of ATM solutions and hence the need for global interoperability.

You can download the ASBU from here.

The ASBU module library is available here.

This article was written in part using ICAO material.

Budapest Ferihegy Airport has two terminals. Terminal 1 is the old terminal and was used lately by the low-fare airlines. Terminal 2 A and B is the new facility, one of which was used exclusively by Malev and which was left vacant after the failure of the Hungarian airline.

When Ryanair arrived, they drove a hard bargain with the airport company and ended up using the former Malev part of Terminal 2 but! Ryanair does not use airbridges and passengers are supposed to walk to their aircraft wherever the low-fare airline operates. But those are typically second tier airports where the walking distance is limited. Not so at Ferihegy where the airport was built to use buses for the remote stands which are located quite some distance from the building itself.

I guess the managers of the airport and the security folks were breaking out in a cold sweat for several days when they imagined a 737 planeload of passengers trotting in the rain from the exit to the parked aircraft… some of them straying, others trying to come back… horrible! Clearly, something had to be done.

Well, the solution they came up with is what you see on the picture above. Depending on your temperament and experience, you might say this makes you feel like you were in Disneyland waiting to get on a new ride… or you will say this is not for people but only  for cattle.

Sic Transit Gloria Mundi!

This Airbus in old Air France livery may not equal the beauty of a Super Constellation but in her own way she is also nice.