Local Area Networks (LANs) in Aircraft - FTP Directory Listing - FAA

alternative requires that parallel (i.e., distinct) sets of onboard networks and wireless external
communications systems be created, one for passengers and one for the other aircraft systems.
The figure 3 approach, therefore, has a higher SWAP overhead than the figure 1 approach, by
requiring parallel internal (onboard LAN) and external network (radio, satellite, etc.)
connectivity, without significantly improving the security profile for the aircraft itself.
3. EXTENDING THE CURRENT FAA CERTIFICATION ENVIRONMENT.
The purpose of this section is to provide an orientation for how this study recommends that the
certification environment be extended to handle networked airborne LANs. The specific theory,
rationale, and process underlying this study’s recommendations are explained in subsequent
sections (i.e., sections 6, 7, and 8).
It was previously mentioned that current FAA and civil aviation safety assurance processes for
airborne systems are based on ARP 4754, ARP 4761, and the ACs. FAA software assurance is
based on compliance with DO-178B, and complex electronic hardware design assurance is based
on DO-254. The primary FAA certification standards are the respective regulations, FAA
policy, and the ACs. This study addresses how to extend these processes and certification
environment to include networked airborne LANs in a mathematically viable manner. Because
of the large scope of the current FAA policies and processes, this report addresses this larger task
by explaining how to specifically extend its airborne software assurance subset.
Figure 5 shows a simplified and abstracted view of the current FAA software assurance approval
process. It shows that airborne software is currently developed and approved primarily
according to the guidance and processes described within DO-178B. 2 When individual software
items are combined into integrated or complex systems, then additional safety considerations
apply, which are documented in ARP 4754. These considerations address integration issues and
system vulnerabilities that may arise from system dependencies. ARP 4754 refers to each
element within that system as being an item. This same terminology is adopted by this study.
DO-178B builds upon system design concepts such as the AC 25.1309-1A fail safe design
concepts, one of which is integrity. Both DO-178B and ARP 4754 (i.e., section 2.2.2 of
DO-178B, where it is called the “software level definitions,” and Table 3 of ARP 4754) rely
upon the same five failure condition categories. Indeed, the same failure condition categories are
consistently used within other civil aviation documents as well (e.g., Table 2-1 of DO-254 and
Table 1 of ARP 4761). Different development processes are applied to items classified in
different failure condition categories so that items classified in the more severe safety failure
conditions are developed by more extensive processes that produce higher assurance results. For
software items, this is reflected in the DO-178B software level definitions. For this reason, this
report refers to DO-178B software levels as reflecting safety assurance levels.
2 There are other applicable policies and guidance in addition to DO-178B that can also be applied. Please recall
that this figure is a simplified abstraction.
15