• 热门标签

当前位置: 主页 > 航空资料 > 国外资料 >

时间:2010-08-31 18:45来源:蓝天飞行翻译 作者:admin
曝光台 注意防骗 网曝天猫店富美金盛家居专营店坑蒙拐骗欺诈消费者

However, in order to assess the human factors aspects of these devices, it may be necessary to host
emulation software on the platform. This may be a dedicated software package developed purely for
the purposes of conducting the assessment or be one or more of the intended EFB software
applications. The human factors assessment should be conducted in accordance with the criteria
applied during the aircraft type design or modification exercise and identified within the aircraft
FLIGHT SAFETY FOUNDATION • FLIGHT SAFETY DIGEST • JUNE 2005 17
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-7 01.10.04
certification basis. If no prior human factors requirements have been applied, the applicant should
follow the process described in Appendix D.
6.1.4 Certification Documentation
a) Aircraft Flight Manual
For Class 2 and 3 EFB the Aircraft Flight Manual (AFM) should contain any limitations affecting the
use of the EFB system e.g., a statement that a particular function is not intended as a primary
navigation reference. Note: under certain circumstances a placard mounted adjacent to the EFB
display might also be warranted. The AFM should also make reference to any applicable guidelines
for application developers, operators and national authorities – see chapter 6.1.4.b below.
b) Guidelines for EFB Application Developers
The guideline document should provide a set of requirements and guidelines to design, develop and
integrate software applications into the EFB host platform. It is intended primarily for use by software
application developers, but may also be of use to the operator and the JOEB and/or National
Authority. The guideline should address at least the following:
• A description of the architecture for the host platform
• Information necessary in order to define a software application, including library routines
etc.
• The EFB Design Assurance Level (DAL) and any assumptions, limitations or risk
mitigations made in support of this
• Information necessary to ensure development of a software application consistent with
the avionics interface and the human machine interface, that is also accurate, reliable,
secure, testable, and maintainable
• Rules of co-habitation of any new software application with those already approved
• Guidelines on how to integrate any new software application into the platform
• A quality assurance process for developing software applications in the context of the
host platform
6.2 EFB Software Applications (Type A and B)
Type A and B software applications do not require airworthiness approval, but should be approved
through the operational approval process. Examples of Type A and Type B software applications,
based mainly on FAA AC 120-76A, are given in Appendix A and B of this leaflet respectively. Some
differences with FAA AC 120-76A have been introduced and are highlighted in these appendices. If a
software application is not listed in these appendices and does not clearly fall into the existing
definitions of Section 5.2, advice should be sought from the Central JAA or relevant JOEB Team, or
the responsible National Authority.
a) Applications Ineligible for Type A or Type B EFB Classification
It should be noted that, unlike FAA AC 120-76A, this Leaflet does not include a Type C software
application classification. The JAA policy is that any software application not falling within the scope
of Type A or Type B should undergo a full airworthiness approval. This is consistent with the FAA
policy for Type C software applications under the Advisory Circular, but eliminates the confusion of
what is Type C EFB and what is normal aircraft function. This has been a particular issue with Class
3 hardware platforms where other non-EFB functions may be hosted requiring separate airworthiness
approval. By removing Type C, in terms of airworthiness assessment all non Type A and Type B
software applications are treated the same as non-EFB functions. Examples of software applications
that the JAA consider to be ineligible for Type A or Type B EFB classification are provided in
Appendix C.
b) Specific Considerations for Performance and Electronic Checklist Applications
Although the airworthiness authority is not directly involved in the approval of Type B software
applications such as performance calculations (weight & balance, take-off and landing performance)
and electronic checklist, they may become indirectly involved.
Performance applications are typically derived from Computerised AFM Information, approved against
the applicable airworthiness regulations. Only certain modules of the performance program are
 
中国航空网 www.aero.cn
航空翻译 www.aviation.cn
本文链接地址:航空资料31(90)