CASE STUDY: Introducing and integrating a new performance solution at Air Nostrum

Author: Juan Diaz, Head of Flight Support, Air Nostrum

Subscribe

Juan Diaz, Head of Flight Support at Air Nostrum shares the implementation of a new aircraft performance solution: implementation, and data integration with EFB and ETL systems

With a case study, it’s always useful to know something of the environment in which the case was carried through; so, before diving into the study itself, I’ll share with readers some information about Air Nostrum, Flygprestanda and Guru2.

AIR NOSTRUM

A European regional airline, Air Nostrum is headquartered in Valencia and has about 1,500 employees. It mainly flies out of Madrid for Iberia feeder flights and some international short-hauls. We operate around 200 flights a day to seven European and North African countries with 130 short to medium direct routes serving about 55 airports.

In 2022, the airline carried some 4.5 million passengers, also reaching the milestones of two million flights and 100 million passengers since starting operations in 1994. In December of this year, Air Nostrum will have been flying for 30 years. In 1997, we signed a franchise agreement with Iberia and became known as Iberia Air Nostrum and now are branded with the Iberia colors.

The first aircraft in the fleet were Fokker 50s then, in 1998, came our first jet, the CRJ 100. Since then, we have incorporated ATRs, Dash-8, CRJ200, CRJ900 and CRJ1000 types. Today, the fleet includes 37 active aircraft: six ATR 72-600, 27 CRJ1000 and four CRJ200.

Now, something about the solution whose implementation in Air Nostrum is the subject of this case study.

FLYGPRESTANDA

Although specializing in aircraft performance solutions since 1969, Flygprestanda also offers applications for mass & balance plus have their own airport database. They are ISO 9001 Certified and EASA/FAA compliant and have been pioneers in EFB development with airline and business jet operator customers worldwide. There is Flygprestanda performance software for over 300 different aircraft types and they have plenty of expertise in integrations with EFB and EFF systems.

One important product is the Dynamic Airport Database which contains more than 10,000 airports with obstacles and they use NOTAM Watch to keep track of any changes. They also design Engine Out procedures when necessary and provide performance information when it’s required. New airports are added to the database on request. The solution can work with most platforms and solutions and can work with either AFM (Aircraft Flight Manual) data or the actual software performance tools that we have or that the manufacturer might be using. All of that information is included with Guru2 which is the EFB performance tool for airlines and operators.

Guru2 – Performance / Mass & Balance Calculator

Available as an iPad or Windows based system, Guru2 also offers an offline Web interface which replicates what pilots would be seeing, if needed.

In one tool, it includes the performance and the mass & balance capabilities. It’s also modular so that if one or the other is not needed, it can just be switched off. It works in portrait or landscape orientation plus it has a night mode which some pilots prefer to use all of the time. As already mentioned, it has 300 aircraft types in the system which covers almost all types in regular service. Even though the CRJ1000 is not used by many operators, Flygprestanda dealt with that. Guru2 integrates the Dynamic Airport Database and helps to calculate things a lot better, making flights easier, safer and more economical while maximizing TOM (Take-Off Mass) and minimizing engine wear. There is also an MEL/CDL (Minimum Equipment List/Configuration Deviation List) capability and, something that we have found interesting, the in-flight landing capabilities where the GRF (Global Reporting Format – ICAO) and LDTA (Landing Distance at Time of Arrival) checks that are required nowadays have been integrated into the system. The solution is fully customizable and can manage app-to-app integrations with API (Application Programming Interface) support, of which more later.

AIR NOSTRUM EFB HISTORY

We’ve had EFBs in Air Nostrum for a while now having got the green light approval process from management in 2018 for EFB. In January 2019, we commenced operational trials which led to final approval by the authorities in August of that year. That approval was only for the CRJ200 and CRJ1000 which remained the case at the time of writing although we hoped to get that approved for the ATR fleet in just a few months. The approval covered charting, documentation, flight folder, OFP (Operational Flight Plan), journey log and mass & balance. We didn’t initially apply for performance at the time and then, when Covid struck, everything was put on hold.

It was 2021 before Air Nostrum started to feel comfortable to expand the EFB set-up into more capabilities with the first thing we went for being Take-Off and Landing (TO/LD) performance software; something that had not been in our initial trials. During 2021, we reviewed what was available, what would work for Air Nostrum and, towards the end of 2022, made a final decision to adopt Flygprestanda’s Guru2. By May 2023 we got the Guru2 set up and got the authority’s approval extended to include TO/LD performance. So now, our EFB includes most of the things that can be included. We are actively looking at the technical log with the intention getting that included within a year.

USING GURU2 BY FLYGPRESTANDA AT AIR NOSTRUM

At Air Nostrum, one thing that we liked about Guru2 was the easy-to-use design, some pilots actually at first thought it too simple, but, in truth, there are only so many ways to present this sort of information, let alone making it visually appealing. The solution is intuitive and that simplicity makes things easy to look at plus, after a while, pilots just got used to it, probably the best endorsement.

There were other things that we liked. Multiple configurations options are there and are easy to select; it’s not something that others don’t have, but it is something we like. Selecting flap configurations from multiple options is relatively easy and intuitive for pilots. We are able to do multiple calculations on the solution, something that pilots like as they prefer to get everything calculated beforehand and this allows them to do optimum calculations. Going from tables to point calculations provides more accurate results and this is, perhaps unsurprisingly, a benefit for Air Nostrum and our pilots; another benefit was the prevention of invalid configurations with warnings. It’s hard to mess things up and get things wrong but, if that does happen, there are different red and orange warnings to warn the pilot that something is wrong.

It’s easy, at the press of a button, for pilots to switch between flex and normal take-off calculations, and then to set things up and work with that. At the time when we were looking at Guru, the LDTA requirement was coming in and Guru2 is able to make those calculations for us. As pilots reading this might know, when you had to go through the tables and the charts and, if you didn’t have a calculator to hand, it was complicated to get the right numbers and know if you could actually land. So, this make that process much easier for us.

Air Nostrum flies to some strange places where connectivity can be a problem – we only have 3G on the iPads – so that sometimes not being able to work online was a worry. Guru2 works well offline which was something that we appreciated. Also appreciated was the ability to use a mixed fleet, to have all of our aircraft in the same application and to not have to worry about cross-training pilots if they’re transferring from one fleet to another. We were also impressed that Flygprestanda is able to work either AFM, SCAP (Standard Computerized Aircraft Performance) or whatever is available depending on the manufacturers. For instance, the CRJ200 is a very old aircraft type so the system had to run off AFMs whereas the CRJ1000 is much newer with SCAPs all through and, with the ATR, we have a bit of a mix. Guru2 is able to cater for all of that.

Observations

There are some things that we found out after nearly a year working with the software. At first, pilots didn’t like the new solution. They were pretty much set in their ways after, in some cases, thirty years with the airline, and thought that it was something that we were imposing on them. It was difficult for them to swallow and there was an initial reluctance to use Guru2. Also, there was a change in the regulatory way of thinking that meant that suddenly, everything had to be documented and that wasn’t easy. Pilots had gone from no-one asking what their values were and how they calculated them to having to document everything, save their data and numbers and so forth; it was a challenge for us. This resulted initially in slower turnarounds. The pilots were used to using some short-cuts without variation but now had to run the calculations every time, every take-off, every landing, so it was slower at first. However, the pilots got used to it and it’s now not that bad.

Lessons learned

We also realized that pilots were typing numbers from one app to another which introduced the possibility of human error. It was because they were using one application for the weight & balance and then manually transferring those take-off and landing data over to Guru2 to do the calculations and get speed values. There was the potential for a manual input error which would mess up all subsequent calculations.

Another thing that we realized was that we were always going to want changes to the product, although we called them improvements, and for that there has to be an open dialogue with the manufacturer to get those sorts of things working.

We had to adapt our training methods, our operations methods and try to be patient with pilots, give them time to get used to the software. To be more aware of their needs and how using Guru2 changes the way they are used to working, would go a long way in getting Guru2 accepted into Air Nostrum and into the airline’s pilot community.

A couple of examples.

At the beginning we detected things such as that, although there was data regarding the distance available and the distance required, that was just numbers. In this example, pilots will see, say, that there is 2528m available runway length and that the flight requires 2277m to take off; but what does that really mean? If you have to start thinking about this, is 300m a lot of leeway or not: what is going on? With wind data, again, you’re inputting data as it’s coming from the METAR but then the pilots had to do a mental calculation because they would actually be flying with headwinds and crosswinds, not only the wind values from METAR. In short, it wasn’t easy to look at those and to see what was going on. We asked Flygprestanda for some kind of a solution and what they came up with a little button at the bottom of the screen with which they could toggle the runway and a little diagram shows up showing the wind component so that the pilots could detect if there was a tailwind, how much crosswind they have and, especially, how much runway will be used and how much is available. Also, if necessary, it gives the pilots a warning status. For example, in figure 5 it’s set up to be 15 percent so, if it goes yellow, it means that they’ve only got 15 percent of the runway left and if it goes into red, then they’re really in trouble. Green or blue means that they’re OK.

It allows them to quickly pick-up on the information as compared to before.

Another thing that we detected was the manual input errors, also how slow some things were. We needed something to speed things up.

We asked Flygprestanda and AVIOBOOK to see what they could come up with. They came up with APIs with which they were able to integrate the systems. So now, Air Nostrum pilots get data from AVIOBOOK, into Guru2 which is then used to do the calculations that they need.

How it used to work was that, going from AVIOBOOK, the pilot has to open up Guru, type in the data – flights, destinations, etc. – and that was something that you’d have to do every single flight. The process was quite slow with inputting the weather data, typing the numbers, get the values, check that everything is in the green, choose the airport, do the same thing for landing and, if you made a mistake, go back and fix it, look at the runways, choose the option and then approve the flight. The whole process took about two minutes.

After the integrations, what AVIOBOOK and Flygprestanda came up with was a little button which the pilot could click, the system asks whether they want to transfer the data across which they do. That creates the flight which already saved time and has transferred the numbers across. So, the pilot only has to click on the weather, check the weight & balance for take-off and landing and the data is approved in about a minute. We’ve already saved one minute simply by integrating the two systems. While that doesn’t, at first, seem much, that’s one minute for every flight of six or seven flight a day which, after a year will amount to a notable time-saving just from being able to transfer the data across perfectly without any issues so that the pilots don’t get it wrong.

Sometimes when transferring weights from AVIOBOOK to Guru2, the values would show decimal points, which Guru2 doesn’t understand and landing weights were missing; so, we asked both vendors to see what can be done about that. I am happy to say that, at the time of writing this article, this has been solved and the transfer of data is working correctly.

SUMMING UP

We’re able to use one application for all of our fleets at Air Nostrum; all of the airports we use are in the database so pilots don’t have to worry about where they’re going – they’ll have the data and be able to safely calculate the landing and take-off. When compared with tables, Guru2 gives pilots a lot more accuracy resulting in more precise results, allowing with ease the use of different configurations and actual weather values, and we feel that it also improves their situational awareness as to what’s going on, what they’re doing and they are able to quickly calculate going from one section to another or even running one-offs.

Now that our pilots have been using Guru2 for about a year, most of them would not wish to go back to the tables.