CASE STUDY: Peach Aviation optimizes airport and obstacle data management

Author: Yuya Maeda, Performance Engineer, Peach Aviation

Subscribe

Yuya Maeda, a Performance Engineer at Peach Aviation, explains how a semi-automated NOTAM assessment tool developed with NABLA Mobility addresses the challenges of obstacle evaluation by optimizing data for takeoff and landing calculations.

This article is primarily about having better and more detailed obstacle avoidance information: But first, and in order to give readers some context, I’ll start by introducing Peach Aviation, explaining the process of NOTAM (Notice to Airmen) evaluation and the challenges we had before implementing the new system. Then, I’ll look at the new system, its function and the benefits we gained. Lastly, I’ll explain how we continue to improve the system.

PEACH AVIATION

Founded in 2011 and based in Osaka, Japan, Peach Aviation is a group airline in the ANA (All Nippon Airways) Group, operating 40 routes, mainly in Asia, from Osaka and Narita in Tokyo. We also fly to China, Korea and Singapore. Our fleet of 35 aircraft includes the Airbus A320ceo, A320neo and A321LR.

Figure 1

DATA MANAGEMENT FOR OBSTACLE NOTAMS

Peach Aviation relies on data management to monitor obstacle NOTAMs; the OCC (Operations Control Center) and flight operation engineers are responsible for monitoring obstacle NOTAMs. That process used to be done manually, so it took a lot of time. When there is an obstacle, such as trees, buildings, construction or a construction crane in the takeoff area, we have to assess it in terms of the power-to-mass calculation. The flight area shown in figure 1 identifies a takeoff flight path area, located after the end of the runway. Prior to takeoff, the pilots and dispatcher calculate the takeoff weight and speed to ensure that the aircraft can clear all the obstacles.

Figure 2

Monitoring and evaluating obstacles

There are several ways to manage obstacle data. At Peach Aviation, as mentioned above, teams from OCC and our freight operational engineers are responsible for monitoring obstacle NOTAMs. The OCC receives all the NOTAMs and checks the position of obstacles by plotting them on a map. They check if the obstacle is within the takeoff area and, if it is, they notify the flight operations team.

Our flight operations team monitors and evaluates the obstacle notes from airports, so we can confirm whether the obstacle could have an impact on takeoff performance. We verify the position and the height of the obstacle and, if it has an impact on takeoff performance, we update the Airbus FlySmart database.

Time-consuming effort

The challenge we had with the process is that the orthogonal NOTAM assessment is a time-consuming process – inputting NOTAMs, evaluating them and updating the database was done manually. That made for a large workload for OCC and the flight operation engineers.

Figure 3

Because NOTAMs are published daily at all airports, the OCC had to check for NOTAMs every day. It took one to two hours to evaluate, complete the evaluation accurately and update the EHV/EFB database. As our operation grew, our routes and fleet expanded, so we had to check more NOTAMs, which further increased our workload, as you can see in figure 4.

Figure 4

EVALUATING OBSTACLES

To evaluate an obstacle, we used Google Earth to measure distances from the runway, as shown in figure 5, by overlaying a takeoff flight path. This was done by noting the coordinate position of the obstacle noted in the NOTAM and plotting it on Google Earth, then using a spreadsheet to manage the database.

Figure 5

Once the measured distance had been entered into the spreadsheet, we could check whether or not it had an impact. However, there was a risk of errors and measured distances might vary depending on the engineer who calculated them.

Turning after takeoff

The turning departure is much more complicated. In some airports, we are instructed to turn immediately right or left after takeoff. Figure 6 shows Haneda Airport in Tokyo, where we have to take a right turn after takeoff (the red line on the map).

Figure 6

To do this, we overlaid a Type-A chart (shown in white in the diagram on Google Earth). We had to calculate the straight-line part and the curved flight path. For a curved flight path, we made drawings to get the radius and angles. These tasks took time to complete, and our team wanted to avoid having to do them. To remedy this, we decided to implement a system to automate part of the process. The results are time savings and reduced workload.

SOLVING THE PROBLEM

To solve the problem, we decided to implement a system that automates the data management process. Our flight operational engineers and OCC discussed what to do. Firstly, simple NOTAM input is a necessary feature, so the solution had to be easy to use. Secondly, the system had to read information automatically, visualize it on a map and measure the necessary distances for take-off and performance evaluation. Easy communication across the OCC and flight operations teams was also an important requirement.

Figure 7

A single integrated system

As we manage the runway database in a spreadsheet, we wanted to integrate it into one system, so airport and obstacle data can be managed together. When obstacle data or runway data is updated, we have to reflect it in the EHV [or EFB?] database. Also, we needed an export function, in order to be able to update the database faster.

From these functions, we expected that the process of evaluation could be done accurately and instantly. Furthermore, the workload for OCC and the flight operation engineers needed to be reduced, so engineers could focus on other tasks, and flight dispatchers could spend more time on flight planning. Automating the process would eliminate people-dependent tasks, enabling us to deliver the necessary information to pilots without delay and improve operational efficiency.

COLLABORATION PAYS OFF

We decided to develop this system with NABLA Mobility, a Japan-based startup company. Peach already has a long-standing collaboration with NABLA Mobility on fuel-mitigation and turbulence avoidance projects, including an EFB (Electronic Flight Bag) solution. Given that we are used to working together, Peach Aviation decided to collaborate with NABLA Mobility to develop a semi-automated obstacle data system for reliable, faster and efficient processing. NABLA Mobility’s turbulence avoidance system already works on an iPad, which is convenient to use, and we knew that they offered good support and understood our needs.

Figure 8

HOW THE SOLUTION WORKS

When we receive a NOTAM, we copy and paste it into the system, which automatically redirects NOTAM information, such as airport or effective date. When you click the map tab, the obstacles are visualized automatically, and the distance is measured in a few seconds. For timing departure cases, it was very complicated, but now we just paste the NOTAM and the evaluation process is completed in less than one minute. We have reduced a lot of our workload and minimized the amount of manual work required.

Obstacle data management

We also implemented a function to evaluate the obstacle vertically. On the left side of figure 9, we assume that there are four buildings in the take-off path area, and the third obstacle is lower than the second obstacle. In this case, as there is no impact on takeoff performance, we don’t have to reflect the second obstacle on the ESV (Expanded Service Volume) / EFB database and we can reduce the number of updates needed. This helps us to improve operational efficiency. The right side of figure 9 shows that when the obstacles are small and below a 1.2 percent slope, then they can be removed as well.

Figure 9

Obstacle data is usually published in AIP (Aeronautical Information Publications) and Norton, and, in Japan, it is published in KML (Keynote Markup Language) and Excel files as shown in figure 10. The system automatically detects and locates the position of the obstacle, evaluates the obstacle, and removes any that are outside the takeoff path area.

Figure 10

We can also see how many obstacles are listed. On the right side of figure 11, the red icons mean a new NOTAM has been input by OCC and has to be checked by our flight operation engineers. When the flight operation engineers complete the evaluation, we change the icon to green. Using this function, we can see the status of a process and it is easier to communicate this with each other.

Figure 11

Runway data management

We’ve dealt with obstacle data management. Now I’d like to look at runway data management, see figure 12, such as runway lengths, which are published in AIP. We were using a spreadsheet-managed database, but we integrated the database management system into one system, so now the runway data from AIP can be input and updated in a single system to simplify how we manage the data.

Figure 12

Usually, runway data is updated on the AIRAC (Aeronautical Information Regulation and Control) cycle every 28 days. We have to select the appropriate AIRAC cycles for us. For example, when the normal data is updated on the next error cycle, we can select the appropriate target error cycles and update the database. On the right side of figure 13, we have the modification history record functions. All the timelines and all the modified parameters are recorded, so we can view which parameters are modified.

Figure 13

Taking account of obstacle shapes

Another consideration is that there are different kinds of NOTAM published. In one type of NOTAM, there are multiple obstacles or multiple coordinates written in the NOTAM and the obstacle has a shape. The system automatically identifies the shape of the obstacle and measures distances accordingly.

For example, in figure 14, you can see a mountain area to the left, so we have our own flight path to avoid it. We import this flight path into the system in KML format, and then the system can analyze the information based on our flight path.

Figure 14

BENEFITS OF THE NEW SYSTEM

The flight dispatcher simply copies and pastes the NOTAM into the system, which automatically starts the evaluation, as in figure 15, reads the coordinates from the NOTAM, visualizes it on a map and measures distances. The most complicated part has been replaced as it is automated. We have eliminated people-dependent tasks to minimize input errors, including inconsistencies of measurement.

Figure 15

Time savings are significant. For the flight dispatcher, we save about 90 seconds per obstacle NOTAM. This number may seem small, but we have about 70 NOTAMs a month. That means we can save 105 minutes a month. The more NOTAMs you have to check, the more time you can save. For flight operation engineers, we save about 15 minutes per NOTAM. In addition, we save more than an hour for AIP obstacle data in Japan.

Now, we use AIPs and NOTAMs as a data source (see figure 16), whereas before, we were using the spreadsheet and Google Earth as a data management tool. Now, those tools are replaced by one integrated system, so the normal data and obstacle data management is simplified.

Figure 16

LOOKING TO THE FUTURE

We are continuing to improve the system, starting with expanding the readable obstacle data. In Japan and some countries in Asia, obstacles are also published in AIP supplements. This year, we are developing an automated process for AIP supplements. In many countries, the Type-A chart you can see on the left of figure 17 is published in PDF format. It contains many obstacles, making it difficult to read. We plan to implement a system where we can easily read the obstacles from Type-A charts in PDFs and NOTAM formats, depending on the countries.

Figure 17

The second point is that we plan to integrate with the same system after its development, so when the NOTAM is published it is automatically entered in the system and the system can start the evaluation.

Thirdly, we plan to implement export functions, so we have runway data and obstacle abort data in the system. And when there is a modification update, we can update the EFB database.

We plan to export the database in a FlySmart-specified format, so we can update the EHV/EFB database faster. By integrating with SWIM (System Wide Information Management)?, and by developing export functions, we plan to automate the full process from the input of NOTAMs to updating the database.

I hope that, in sharing our experience, this case study will be useful for readers faced with similar challenges and/or contemplating a similar change program.