EFB should stand for enhanced flight bag – PART 2

Author: Sébastien Veigneau, President, dgBirds

Subscribe

In part 2, Sébastien Veigneau, dgBirds President and Air France A320 Captain, considers what pilots might want from an EFB and how that can be delivered within the regulatory environment.

WHAT PILOTS WANT

What are the basic needs of a pilot in terms of EFB applications? Let’s identify some of them by using the famous ‘As a pilot, I want…’ identifier from the Agile method.

• As a pilot, I want documentation (i.e. my operational manuals) to be easy to synchronize and access thanks to a great user interface and an efficient search engine.
• As a pilot, I want charts with ‘own ship’ position, both on ground and in flight; a basic need that has not yet been widely achieved. As you know, we use enroute, departure and approach, taxi and parking charts. Today’s solutions roughly correspond to paper solutions where all these charts are distinct. We have the enroute chart in the EFB interface, which is interactive and much better than a paper chart but we have to switch to the approach, taxi and parking charts when needed. That’s not yet a seamless experience.
• As a pilot, I also want specialized calculators, all the applications that, up until now, have been paper based. For instance, a take-off and landing performance calculator. Any pilot having used the paper tables to compute V1, VR, and V2 speeds to take-off on a contaminated runway with one brake INOP (inoperative) knows exactly how such a calculator on an EFB has the potential to change his life and the safety of the flight. I have never seen two pilots having the same results when using a paper take-off performance table: but I have never seen two pilots taking off with two EFBs giving different results.
• As a pilot… I want more, with applications that do much more than replace paper. Car drivers have Waze, pilots want enablers too. Connectivity between aircraft and ground servers is the key to get updated data during a pilot’s full journey.
• As a pilot, I want more than a simple access to my documentation. When do I mainly need to read my documentation? When I am not flying the aircraft. Have you ever seen a pilot learning procedures when flying? No: that’s done well before starting the engines. It is something we do at home. And, for that, we need more than a simple PDF reader. We need a system that helps us acquire the full knowledge required to handle an aircraft. We want to be able to customize our manuals, add notes or bookmarks. We want our personalization to be saved and retained when changing iPad. We also want it to be persistent from a version of a document to the new one. As a pilot, I don’t want to lose the work I have done when studying thousands of pages.

The initial training phase is not all. Manuals are always changing, thanks to regulation changes, fleet modifications or just evolutions; and, as a pilot, it is difficult to be aware of all these changes. I have to compare the current and future version of my operational manuals in order to take into account the main points of their revised versions at each AIRAC (Aeronautical Information Regulation and Control) cycle, every 28 days. Moreover, it has to be done before flying: these revisions and updates cannot be learned about upon arriving at the airport. It is quite easy to consider a new procedure but it has always been difficult to forget the previous one. As a pilot, I need specific tools to be aware of the continuous evolution of limitations, procedures, either normal or abnormal, or patterns for instance.

When flying, how do I mainly use my documentation? In fact, not that much: all pilots would say that we don’t need our documentation to fly. But it’s mandatory to have it onboard. We do use it when looking for information on MEL (Minimum Equipment List) or CDL (Configuration Deviation List) items or when we have to perform an unusual procedure, such as a take-off in wind shear conditions. So, what we really need onboard is a very efficient search engine and an immediate access to some well-chosen pages, such as the one showing the pitch attitude and N1% to fly with airspeed unreliable.

More than a chart

What’s the difference between flying an airway enroute, and flying a STAR (Standard Terminal Arrival Route)? No difference: it’s flying between waypoints with altitude and/or speed constraints. We can understand that the enroute and approaches charts were different when represented on a paper. But why are they still different when digitalized? We expect a data driven charting solution, because it gives a far better user experience, that really makes sense for a pilot. From cruise, I should be able to start descent without changing anything on my chart, then join the STAR and see the constraints by zooming in, then follow the final approach with all details needed to check my trajectory, and finally be able to taxi to the gate thanks to a maximum level of zoom giving me relevant information for this part of the flight. When changing to STAR, approach or landing runway, getting the details to check the FMS should not be a supplementary workload for pilots. It should be seamless.

On a taxi chart, I want to be able to easily identity a closed taxiway as stated in a NOTAM (NOTification to AirMen), such as this one: ‘TWY CB BTN RWY 13L/31R AND TWY C CLSD TO ACFT WINGSPAN MORE THAN 143FT NO SE TURNS ONTO TWY C’.

Today, some aircraft are equipped with an application dedicated to taxi, named AMM (Airport Moving Map). But in general, there is another application or another part of the charting application, to get all details about taxi procedures. We know why this situation occurs: at the beginning there was only a paper chart to taxi and then it became an electronic chart. Subsequently, AMM applications have been developed to show the own ship position on ground on a georeferenced chart of the airport. But now, we want all information at the same place. Otherwise we will have to multiply the number of screens we need to display information simultaneously.

More than a calculator

About take-off performance calculations: as stated above, pilots were very happy with the improvement gained when an electronic calculator was introduced to replace a manual and quite haphazard computation. But the main business case was not for pilots but for engine maintenance thanks to the more accurate computation that allowed the thrust to be reduced a little bit more during each take-off.

So, as pilots, we expect better situational awareness than just reading figures computed by a black boxed algorithm. That’s not an impossible dream: it could be a reality now. We expect an interface showing the runway with its intersections, the current position of the aircraft, NOTAMs affecting the runway length depicted as forbidden zones of work in progress for instance, and those affecting the climb-out areas due to new obstacles, described by an always difficult to assess text, to be replaced by a graphical representation. We expect the computed take-off distances (all engines, one engine out, etc.) displayed from the chosen intersection, versus the intersection we are currently taking off from. The idea is to have a better understanding of the take-off performances we can expect, before taking off, but also when lining up to avoid any gross error, such as taking off by night on an unexpectedly shortened runway. In other words, we expect a deeper connection between the real world and the tools available to pilots on their EFBs.

More with connectivity

In a world where aircraft are connected to what we may call ‘IntAirNet’, the internet of the air, weather data could be updated in almost real time to provide a virtual augmented radar image of the weather situations in which and towards which the plane is flying. It could include turbulence reports made by other aircraft in the same area. When connected, the aircraft can be seen as a sensor, emitting data used in a virtuous circle by other aircraft in real-time. As a pilot, I don’t so much want an Electronic Flight Bag as an Enhanced Flight Bag fed by collaborative sources, where applications are sets of functions that enhance my situational awareness. A new level of operational efficiency and flight safety improvement will come from information sharing, collaborative algorithms and overall or individual gained experience. Big Data, Machine Learning and Artificial Intelligence are entering the game.

DELINEATING BETWEEN TWO PRIORITIES

Coming back to our example of the Airport Moving Map and the taxi chart, the point is that airframe OEMs need to decide if these two functions should be joined or separated. Onboard, there is a dedicated screen to display navigation information: the so-called ND (Navigation Display). Historically, it was dedicated to navigate in flight, but recent aircraft include navigation on ground on this display. It clearly makes sense for a pilot but the information should be amended by real-time NOTAMs otherwise there is no chance that pilots have, in front of them, a good and current representation of the situation. That’s funny because it took a number of years to get the approval to have an Airport Moving Map application on a non-airworthiness certified platform, and now it may happen that this moving map comes back to the Navigation Display. Anyway, all this is just an example that does not change the question the industry has to solve: what is permitted and what is not on an EFB?

Functions to operate an aircraft

What are the principal functions a pilot carries out to operate an aircraft?

• ‘Fly’ refers to monitoring and controlling the aircraft flight parameters in order to achieve and maintain a desired flight path.
• ‘Navigate’ refers to determining where the aircraft is, where it should be, and where it should go.
• ‘Communicate’ refers to communication between all stakeholders of the flight – flight crew members, ATC (Air Traffic Control) cabin crew, company ground staff.
• ‘Manage systems’ refers to the pilot’s actions to monitor and control the aircraft systems.
• ‘Construct & maintain situational awareness’ refers to building and maintaining a mental picture of the aircraft and its situation with respect to its environment, e.g. weather, terrain and obstacles, traffic, airspaces and country boundaries…
• ‘Support Mission’ refers to a pilot’s consultation of reference information and computation of ‘flight-related’ information, e.g. take-off and landing performances, mass & balance… and any other information supporting the flight. Together with actions performed before the flight or after the flight in relation to the flight.
• ‘Manage Logistics’ refers to the tasks non-related to the conduct of the flight.

Drawing a clear line to support innovation

Now, because an EFB is by definition a non-airworthiness certified platform, the industry has to decide what are the applications allowed on an EFB and what are those that should be forbidden. Drawing a clear delineation between the airworthiness certified world and the operationally approved one will boost innovation in the EFB domain. The tendency is to forbid any function used to substitute or duplicate the intended use of instruments or equipment required by airworthiness regulations, airspace requirements, or operational rules. But also, to forbid all uses intended to fly, to navigate, to communicate with ATC, and any function used as a primary means to monitor the real-time status of aircraft critical and essential systems, or to alert so that it requires immediate crew awareness and/or responses, or any use to control aircraft critical and essential systems.

You may think it is quite limitative but there is another way to see things. Stating clearly what is forbidden on an EFB, gives a chance to all other functions to be approved. This work is in progress by EUROCAE Working Group 106, on behalf of EASA. This work should support, rather than hinder, innovation.

Looking ahead

It will be very important to anticipate further developments of the EFB in future years in order to ensure that innovation in the cockpit continues. That’s why it is so important to draw this delineation between the avionics airworthiness certified world and the operationally approved software domain; but also to define a clear process to assess a candidate EFB function. One important stage has been reached about the assessment of a candidate EFB function: if the risk assessment outcome (regarding the two hazards: loss of the function and display of erroneous output) of a function is higher than ‘minor effect on safety’, it would normally lead to a refusal for that function to be executed on an EFB. Thanks to some mitigation means, it is permissible to mitigate the severity effect of the two hazards (i.e. to reduce the impact, or increase likelihood to detect an error after it happens) if this severity is assessed as greater than minor. But now, after mitigation, if the severity is still greater than minor, i.e. there is a residual risk, it is possible to define prevention means to prevent the hazard from happening or reduce its likelihood. Once again, this opens the door for innovation; offering EFB software developers the opportunity to demonstrate the eligibility of their proposed new EFB functions to become an approved EFB function.

A few questions before we move on: should the industry allow…

• ADS-B data to be shown on an EFB for trajectory optimization purposes?
• A 3D virtual aircraft representation for a better pilot’s situational awareness in case of upset recovery?
• Crystal icing zones displayed on a map with own ship position, while it is still not detected by legacy radars?

These are all questions for the future. However, the industry has to decide more immediately on which side of the delineation they should fall. Part 3 in the next issue will look to future challenges and opportunities to ensure that EFB can meet what pilots and airlines need.

Contributor’s Details

Sébastien Veigneau

After teaching computer science and as a TRI while flying A320 and B777, Sébastien is now flying the A320 as Captain at Air France. With a PhD in Computer Science and his Air Transport Pilot License, he developed software solutions before introducing the iPad for Air France pilots in 2012. As an EFB expert, he participated to the EASA RMT 601/602. In 2017, he co-created and became President of dgBirds, AF subsidiary.

DG Birds

dgBirds is a vibrant company based on many years of experience in designing mobile solutions for professional pilots. In 2010, Air France chose the iPad as an Electronic Flight Bag for its pilots and developed some apps to support their mission. dgBirds was launched in 2017 as a subsidiary of Air France to build on this successful solution used by 4000 pilots. The business is committed to developing and marketing software solutions for any mobile business.