AMC1 NCC.GEN.131(b)(1) Use of electronic flight bags (EFBs)

RISK ASSESSMENT

(a) General

Prior to the use of any EFB system, the operator should perform a risk assessment for all type B EFB applications and for the related hardware as part of its hazard identification and risk management process.

The operator may make use of a risk assessment established by the software developer. However, the operator should ensure that its specific operational environment is taken into account.

The risk assessment should:

(1) evaluate the risks associated with the use of an EFB;

(2) identify potential losses of function or malfunction (with detected and undetected erroneous outputs) and the associated failure scenarios;

(3) analyse the operational consequences of these failure scenarios;

(4) establish mitigating measures; and

(5) ensure that the EFB system (hardware and software) achieves at least the same level of accessibility, usability, and reliability as the means of presentation it replaces.

In considering the accessibility, usability, and reliability of the EFB system, the operator should ensure that the failure of the complete EFB system as well as of individual applications, including corruption or loss of data, and erroneously displayed information, has been assessed and that the risks have been mitigated to an acceptable level.

The operator should ensure that the risk assessments for type B EFB applications are maintained and kept up to date.

When the EFB system is intended to be introduced alongside a paper-based system, only the failures that would not be mitigated by the use of the paper-based system need to be addressed. In all other cases, a complete risk assessment should be performed.

(b) Assessing and mitigating the risks

Some parameters of EFB applications may depend on entries that are made by flight crew/dispatchers, whereas others may be default parameters from within the system that are subject to an administration process (e.g. the runway line-up allowance in an aircraft performance application). In the first case, mitigation means would mainly concern training and flight crew procedure aspects, whereas in the second case, mitigation means would more likely focus on the EFB administration and data management aspects.

The analysis should be specific to the operator concerned and should address at least the following points:

(1) The minimisation of undetected erroneous outputs from applications and assessment of the worst credible scenario;

(2) Erroneous outputs from the software application including:

(i) a description of the corruption scenarios that were analysed; and

(ii) a description of the mitigation means;

(3) Upstream processes including:

(i) the reliability of root data used in applications (e.g. qualified input data, such as databases produced under ED-76/DO-200A, ‘Standards for Processing Aeronautical Data’);

(ii) the software application validation and verification checks according to appropriate industry standards, if applicable; and

(iii) the independence between application software components, e.g. robust partitioning between EFB applications and other airworthiness certified software applications;

(4) A description of the mitigation means to be used following the detected failure of an application, or of a detected erroneous output;

(5) The need for access to an alternate power supply in order to ensure the availability of software applications, especially if they are used as a source of required information.

As part of the mitigation means, the operator should consider establishing a reliable alternative means to provide the information available on the EFB system.

The mitigation means could be, for example, one of, or a combination of, the following:

(1) the system design (including hardware and software);

(2) a backup EFB device, possibly supplied from a different power source;

(3) EFB applications being hosted on more than one platform;

(4) a paper backup (e.g. quick reference handbook (QRH)); and

(5) procedural means.

Depending on the outcome of their risk assessment, the operator may also consider performing an operational evaluation test before allowing unrestricted use of its EFB devices and applications.

EFB system design features such as those assuring data integrity and the accuracy of performance calculations (e.g. ‘reasonableness’ or ‘range’ checks) may be integrated in the risk assessment performed by the operator.

(c) Changes

The operator should update its EFB risk assessment based on the planned changes to its EFB system.

However, modifications to the operator’s EFB system which:

(1) do not bring any change to the calculation algorithms and/or to the interface of a type B EFB application;

(2) introduce a new type A EFB application or modify an existing one (provided its software classification remains type A);

(3) do not introduce any additional functionality to an existing type B EFB application;

(4) update an existing database necessary to use an existing type B EFB application; or

(5) do not require a change to the flight crew training or operational procedures,

may be introduced by the operator without having to update its risk assessment.

These changes should, nevertheless, be controlled and properly tested prior to use in flight.

The modifications in the following non-exhaustive list are considered to meet these criteria:

(1) operating system updates;

(2) chart or airport database updates;

(3) updates to introduce fixes (patches); and

(4) installation and modification of a type A EFB application.