曝光臺 注意防騙 網曝天貓店富美金盛家居專營店坑蒙拐騙欺詐消費者

“contextual access” like hyperlink, bookmark.
5. SYSTEM DESCRIPTION AND CLASSIFICATION OF EFB Systems
This section is divided into two parts. The first part deals with the host platform i.e. the hardware used
to run the software programs and the second part deals with the software programs or applications
installed to provide the relevant functionality. For information, a matrix showing the relationship
between airworthiness and operational approval processes is provided in Appendix E.
5.1 Hardware Classes of EFB Systems
This Leaflet defines three hardware classes of EFB systems, Class 1, 2, and 3.
5.1.1 Class 1
Class 1 EFB systems are:
• Generally Commercial-Off-The-Shelf (COTS)-based computer systems used for aircraft
operations,
• Portable,
• Connect to aircraft power through a certified power source,
• Not attached to an aircraft mounting device,
• Considered as a controlled PED,
• Normally without aircraft data connectivity except under specific condition (see Section 6),
• Class 1 EFB systems do not require airworthiness approval.
5.1.2 Class 2
Class 2 EFB systems are:
• Generally COTS-based computer systems used for aircraft operations,
• Portable,
• Connect to aircraft power through a certified power source,
• Connected to an aircraft mounting device during normal operations,
• Considered as a controlled PED,
• Connectivity to Avionics is possible,
• Class 2 EFB systems require airworthiness approval as described in Section 6.
5.1.3 Class 3
Class 3 EFB systems are installed equipment requiring an airworthiness approval. This approval
should cover the integrity of the EFB hardware installation (e.g. server, display, keyboard, power,
switching), including hardware and software qualification. Such aspects as the human machine
interface should also be addressed.
5.2 Software Applications for EFB Systems
The functionality associated with the EFB System depends upon the applications loaded on the host.
The classification of the applications into two Types (A and B) is intended to provide clear divisions
between the scope and therefore the approval process applied to each one. Although guidelines and
examples are provided in this leaflet to provide guidance as to the Type associated with a particular
1 4 FLIGHT SAFETY FOUNDATION • FLIGHT SAFETY DIGEST • JUNE 2005
A P P E N D I X
JAA Administrative & Guidance Material
Section Four: Operations, Part Three: Temporary Guidance Leaflets (JAR-OPS)
Section 4/Part 3 (JAR-OPS) 36-4 01.10.04
application, there is still the potential for misclassification. Applicants should be aware of two
particular issues. The Type of application will influence the level of participation of the operations
authority i.e. National Authority Flight Operations Inspectorate (FOI) or Joint Operational Evaluation
Board (JOEB) and indeed the involvement or otherwise of the airworthiness authorities in the
assessment exercise. For example, a misclassification may later be shown to have impacted the
underlying airworthiness approval granted for the aircraft systems. In particular where there is data
connectivity or interactive information the assumptions made by the Original Equipment Manufacturer
(OEM) during initial certification may no longer hold e.g. data integrity, accuracy of performance
calculations, primary use versus situational use. Therefore, if there is any doubt as to the
classification of an application, applicants should seek advice early on in the approval process from
either the respective JOEB Team or Central JAA Operations Directorate.
5.2.1 Type A
Type A software applications include pre-composed, fixed presentations of data currently presented in
paper format. Type A software applications:
• May be hosted on any of the hardware classes
• Require Operational approval. This may be undertaken at the National Authority FOI level.
• Do not require an airworthiness approval
• Typical examples of Type A software applications may be found in Appendix A.
5.2.2 Type B
Type B software applications include dynamic, interactive applications that can manipulate data and
presentation. Type B applications:
• May be hosted on any of the hardware classes
• Require Operational approval. This will be undertaken at the JOEB level or where a JOEB
does not exist for the particular aircraft type, the Central JAA may delegate to a National
Authority FOI.
• Do not require an airworthiness approval
• Typical examples of Type B software applications may be found in Appendix B.
6. AIRWORTHINESS APPROVAL
　
中國航空網 www.k6050.com
航空翻譯 www.aviation.cn
本文鏈接地址：航空資料31(87)