AMC5 SPA.EFB.100(b)(3) Use of electronic flight bags (EFBs) – Operational approval    

CAA ORS9 Decision No. 1

PERFORMANCE AND MASS AND BALANCE APPLICATIONS

(a) General

Performance and mass and balance applications should be based on existing published data found in the AFM or performance manual, and should account for the applicable CAT.POL performance requirements. The applications may use algorithms or data spreadsheets to determine results. They may have the capability to interpolate within the information contained in the published data for the particular aircraft but they should not extrapolate beyond it.

To protect against intentional and unintentional modifications, the integrity of the database files related to performance and to mass and balance (the performance database, airport database, etc.) should be checked by the program before performing any calculations. This check can be run once at the start-up of the application.

Each software version should be identified by a unique version number. The compatibility between specific modules of a performance or mass and balance software application and the specific software revisions installed on a specific host (e.g. model of computer) should be ensured. The performance and mass and balance applications should record each computation performed (inputs and outputs) and the operator should have procedures in place to retain this information for at least 3 months.

The operator should ensure that aircraft performance or mass and balance data provided by the application is correct compared with the data derived from the AFM (e.g. for take-off and landing performance data) or from other reference data sources (e.g. mass and balance manuals or databases, in-flight performance manuals or databases) under a representative cross-check of conditions (e.g. for take-off and landing performance applications: take-off and landing performance data on dry, wet, and contaminated runways, with different wind conditions and aerodrome pressure altitudes, etc.).

The operator should establish procedures to define any new roles that the flight crew and, if applicable, the flight dispatcher, may have in creating, reviewing, and using performance calculations supported by EFB systems. In particular, the procedures should address cases where discrepancies are identified by the flight crew.

(b) Testing

The demonstration of the compliance of a performance or mass and balance application should include evidence of the software testing activities performed with the software version candidate for operational use.

The testing can be performed by either the operator or a third party, as long as the testing process is documented and the responsibilities are identified.

The testing activities should include human–machine interface (HMI) testing, reliability testing, and accuracy testing.

HMI testing should demonstrate that the application is not prone to error and that calculation errors can be detected by the flight crew with the proposed procedures. The testing should demonstrate that the applicable HMI guidelines are followed, and that the HMI is implemented as specified by the application developer and in paragraph (f).

Reliability testing should show that the application in its operating environment (operating system (OS) and hardware included) is stable and deterministic, i.e. identical answers are generated each time the process is entered with identical parameters.

Accuracy testing should demonstrate that the aircraft performance or mass and balance computations provided by the application are correct in comparison with data derived from the AFM or other reference data sources, under a representative cross section of conditions (e.g. for take-off and landing performance applications: runway state and slope, different wind conditions and pressure altitudes, various aircraft configurations including failures with a performance impact, etc.).

The demonstration should include a sufficient number of comparison results from representative calculations throughout the entire operating envelope of the aircraft, considering corner points, routine and break points.

Any difference compared to the reference data that is judged significant should be examined and explained. When differences are due to more conservative calculations or reduced margins that were purposely built into the approved data, this approach should be clearly mentioned. Compliance with the applicable certification and operational rules needs to be demonstrated in any case.

The testing method should be described. The testing may be automated when all the required data is available in an appropriate electronic format, but in addition to performing thorough monitoring of the correct functioning and design of the testing tools and procedures, operators are strongly suggested to perform additional manual verification. It could be based on a few scenarios for each chart or table of the reference data, including both operationally representative scenarios and ‘corner-case’ scenarios.

The testing of a software revision should, in addition, include non-regression testing and testing of any fix or change.

Furthermore, an operator should perform tests related to its customisation of the applications and to any element pertinent to its operation that was not covered at an earlier stage (e.g. airport database verification).

(c) Procedures

Specific care is needed regarding the flight crew procedures concerning take-off and landing performance or mass and balance applications. The flight crew procedures should ensure that:

(1) calculations are performed independently by each flight crew member before data outputs are accepted for use;

(2) a formal cross-check is made before data outputs are accepted for use; such cross-checks should utilise the independent calculations described above, together with the output of the same data from other sources on the aircraft;

(3) a gross-error check is performed before data outputs are accepted for use; such gross- error checks may use either a ‘rule of thumb’ or the output of the same data from other sources on the aircraft; and

(4) in the event of a loss of functionality of an EFB through either the loss of a single application, or the failure of the device hosting the application, an equivalent level of safety can be maintained; consistency with the EFB risk assessment assumptions should be confirmed.

(d) Training

The training should emphasise the importance of executing all take-off and landing performance or mass and balance calculations in accordance with the SOPs to assure fully independent calculations.

Furthermore, due to optimisations included at various levels in performance applications, flight crew members may be confronted with new procedures and different aircraft behaviour (e.g. the use of multiple flap settings for take-off). The training should be designed and provided accordingly.

Where an application allows the computing of both dispatch results (from regulatory or factored calculations) and other results, the training should highlight the specificities of those results. Depending on the representativeness of the calculations, flight crew members should be trained on any operational margins that might be required.

The training should also address the identification and the review of default values, if any, and assumptions about the aircraft status or environmental conditions made by the application.

(e) Specific considerations for mass and balance applications

In addition to the figures, a diagram displaying the mass and its associated centre-of-gravity (CG) position should be provided.

(f) Human-factors-specific considerations

Input and output data (i.e. results) shall be clearly separated from each other. All the information necessary for a given calculation task should be presented together or be easily accessible.

All input and output data should include correct and unambiguous terms (names), units of measurement (e.g. kg or lb), and, when applicable, an index system and a CG-position declaration (e.g. Arm/%MAC). The units should match the ones from the other flight-crew- compartment sources for the same kind of data.

Airspeeds should be provided in a form that is directly useable in the flight crew compartment, unless the unit clearly indicates otherwise (e.g. Knots Calibrated Air Speed (KCAS)). Any difference between the type of airspeed provided by the EFB application and the type provided by the aircraft flight manual (AFM) or flight crew operating manual (FCOM) performance charts should be mentioned in the flight crew guides and training material.

If the landing performance application allows the computation of both dispatch (regulatory, factored) and other results (e.g. in-flight or unfactored), flight crew members should be made aware of the computation mode used.

(1) Inputs:

The application should allow users to clearly distinguish user entries from default values or entries imported from other aircraft systems.

Performance applications should enable the flight crew to check whether a certain obstacle is included in the performance calculations and/or to include new or revised obstacle information in the performance calculations.

(2) Outputs:

All critical assumptions for performance calculations (e.g. the use of thrust reversers, full or reduced thrust/power rating) should be clearly displayed. The assumptions made about any calculation should be at least as clear to the flight crew members as similar information would be on a tabular chart.

All output data should be available in numbers.

The application should indicate when a set of entries results in an unachievable operation (for instance, a negative stopping margin) with a specific message or colour scheme. This should be done in accordance with the relevant provisions on messages and the use of colours.

In order to allow a smooth workflow and to prevent data entry errors, the layout of the calculation outputs should be such that it is consistent with the data entry interface of the aircraft applications in which the calculation outputs are used (e.g. flight management systems).

(3) Modifications:

The user should be able to easily modify performance calculations, especially when making last minute changes.

The results of calculations and any outdated input fields should be deleted whenever:

(i) modifications are entered;

(ii) the EFB is shut down or the performance application is closed; or

(iii) the EFB or the performance application has been in a standby or ‘background’ mode for too long, i.e. such that it is likely that when it is used again, the inputs or outputs will be outdated.