DOT/FAA/AR·09/24
`
`Air Traffic Organization
`NextGen & Operations Planning
`Office of Research and
`Technology Development
`Washington, DC 20591
`
`Data Network Evaluation
`Criteria Handbook
`
`June 2009
`
`Final Report
`
`This document is available to the U.S. public
`through the National Technical Information
`Services (NTIS), Springfield, Virginia 22161.
`
`U.S. Department of Transportation
`Federal Aviation Administration
`
`I
`DATE
`I ') ~ \~
`REPORTER ~. ~
`Planet Depc11, LLC
`
`Exhibit 1320 Page 001 of 103
`
`

`
`NOTICE
`
`This document is disseminated under the sponsorship of the U.S.
`Department of Transportation in the interest of information exchange. The
`United States Government assumes no liability for the contents or use
`thereof. The United States Government does not endorse products or
`manufacturers. Trade or manufacturer's names appear herein solely
`because they are considered essential to the objective of this report. This
`document does not constitute FAA certification policy. Consult your local
`FAA aircraft certification office as to its use.
`
`This report is available at the Federal Aviation Administration William J .
`Hughes Technical Center's Full-Text Technical Reports page:
`actlibrary.act.faa.gov in Adobe Acrobat portable document format (PDF).
`
`Exhibit 1320 Page 002 of 103
`
`

`
`1. ReportNo
`
`DOT/FAAIAR-09/24
`4 nue and SubliUe
`
`DATA NETWORK EVALUATION CRITERIA HANDBOOK
`
`I 2. Government Accession No
`
`echnical eport Documentation Page
`R
`T
`3. Recipient's Catalog No.
`
`5 Report Dale
`
`June 2009
`6 Performing Organizalion Code
`
`7. Aulhor(s)
`
`6. Performing Organization Report No.
`
`Kevin Driscoll, Breodanllall, Phil Koopman, Justin Ray, and Mike DeWalt
`9 Pcrtorminl) Organization Name and Address
`
`10 Work Unfl No. (TRAIS)
`
`Honeywell International, Inc.
`3660 Technology Drive
`Minneapolis, MN 55418
`12. Sponsoring Agency Name and Address
`
`U.S. Department of Transportation
`Federal Aviation Administration
`Air Traffic Organization NextGen & Operations Planning
`Office of Research and Technology Development
`Washington, DC 20591
`
`15 Supplementary Notes
`
`11. Conlract or Grant No.
`
`DTF ACT .:05-C-00002
`13. Type of Report and Period Covered
`
`14. Sponsoring Agency Code
`AIR-120
`
`The Federal Aviation Administration Airport and Aircraft Safety R&D Division COTR was Charles Kilgore.
`16 Abstract
`
`The purpose of this Handbook is to provide evaluation criteria to be used in the development, selection, modification, adaptation,
`or approval of data network technologies and components to be deployed in safety-critical aviation systems. The expected
`readership for this Handbook primarily includes designers of digital electronics systems that may use data networks and those
`who are concerned with the certification of aircraft or aircraft engines containing such systems.
`
`This Handbook's objective for providing these evaluation criteria is to facilitate the process by which data networks are employed
`in aviation digital electronics systems that may ultimately be certified as part of an overall aircraft or aircraft engine certification
`lt focuses on identifYing aspects of the technologies and component implementations that ultimately may have an
`process.
`adverse impact on the approval within the certification of an aircraft. Pa1ticular attention is given to issues that are generally
`overlooked or underappreciated in the industry.
`
`This Handbook does not constitute Federal Aviation Administration certification policy or guidance, but may be used as input to
`future policy and guidance.
`
`17. Key Words
`
`18. Dislribution Stalemenl
`
`Databus, Network, Certification, Criteria, COTS
`
`19 Securily Classif. (of lhis report)
`Unclassified
`
`Form DOT F 1700.7 (6·72)
`
`I 20
`
`Reproduction of completed page authorized
`
`This document is available to the U.S. public through the
`National Technical Information Service (NTIS), Springfield,
`Virginia 22161.
`Security Classif (of this page)
`Unclassified
`
`21. No. of Pages
`103
`
`I 22 Pnce
`
`Exhibit 1320 Page 003 of 103
`
`

`
`TABLE OF CONTENTS
`
`EXECUTIVE SUMMARY
`
`I.
`
`INTRODUCTION
`
`l.J
`1.2
`
`Organization
`Background
`
`1.2.1 Data Network Evaluation Relative to a System Safety Process
`1.2.2 The CAST-16 Position Paper
`1.2.3 Ethernet Handbook
`1.2.4 Advisory Circular 20-156 Aviation Databus Assurance
`
`1.3
`1.4
`
`Purpose
`Scope
`
`J.4.l System Network Role
`1.4.2 Protocol Stack
`1.4.3 Developmental Time Horizon
`
`2.
`
`DATA NETWORK CERTIFICATION ISSUES IN CONTEXT
`
`2.1
`2.2
`2.3
`
`Supported Application Requirements
`Multiple-Requirement Engineering Trades
`System Architecture and Design
`
`2.3. 1 Determinism
`2.3 .2 Robust Partitioning
`
`3.
`
`PHYSICAL LAYER
`
`3.1
`3.2
`3.3
`3.4
`3.5
`
`Environment
`Probability of Bit Errors
`Probability ofEiectrical Component Failures
`Electrical Isolation Properties
`Physical Cornposability
`
`4.
`
`DATA LINK LAYER
`
`The MAC
`4.1
`Line-Level Encoding
`4.2
`4.3 Message Formating (Framing)
`4.4
`Error Detection
`
`Ill
`
`Page
`
`ix
`
`1
`2
`
`3
`5
`5
`6
`
`6
`7
`
`7
`8
`9
`
`10
`
`10
`10
`1 1
`
`12
`13
`
`l3
`
`13
`14
`15
`15
`16
`
`16
`
`17
`18
`18
`19
`
`Exhibit 1320 Page 004 of 103
`
`

`
`4.4.1 Protocol Violation Error Detection
`4.4.2 Parity and Frame Check Sequences
`4.4.3
`Interactions Between Line-Level Encoding and Error Detection
`
`19
`19
`19
`
`5.
`
`NETWORK LAYER, TRANSPORT LAYER, AND NETWORK MANAGEMENT 20
`
`5.1
`5.2
`5.3
`
`Network Vulnerabil ity to Addressing Information Failure
`Network Vulnerability to Flow Failure
`Impact of Intermediate Stages
`
`5.3.1 Vulnerability to Intermediate-Stage Failure
`5.3.2 Vulnerabi lity of Intermediate Stage to Fault Propagation
`
`5.4
`5.5
`5.6
`5.7
`5.8
`5.9
`
`Network Configuration Data
`Start-Up and Recovery
`Global Synchronization
`Fault Diagnosis
`Client Effect on Network Operations
`Acknowledgement
`
`6.
`
`APPLICATION SERVICES
`
`6.1
`
`Host Interface Management
`
`6.1.1
`6.1.2
`6.1.3
`
`Client Buffer Queue Management
`Buffer Management Partitioning
`Buffer Management Performance Considerations
`
`6.2
`
`Support for Application Layer Redundancy
`
`6.2.1 Support for Active Replication
`6.2.2 Support for Passive Replication
`6.2.3 Support for Increased Integrity
`6.2.4 Support for Robust Partitioning
`
`6.3
`
`Time Service for Time Stamping and Time Interrupts
`
`7.
`
`FAULT TOLERANCE MECHANISMS
`
`7.1
`7.2
`7.3
`7.4
`7.5
`7.6
`7.7
`
`Topological Fault Tolerance
`Guardian Schemes
`Protocol Logic Fault Tolerance
`Local Transmission-Monitoring and Self-Checking Schemes
`Reconfiguration and Degraded Operation
`Latent Failure Detection
`Voting, Selection, or Agreement Services and Redundancy Management
`
`iv
`
`20
`21
`21
`
`22
`22
`
`23
`23
`24
`25
`26
`27
`
`27
`
`28
`
`28
`28
`28
`
`29
`
`29
`30
`30
`31
`
`31
`
`32
`
`32
`32
`33
`34
`34
`35
`35
`
`Exhibit 1320 Page 005 of 103
`
`

`
`7.8
`
`Byzantine Fault Tolerance
`
`8.
`
`DESIGN ASSURANCE
`
`8. 1
`8.2
`
`Development Processes
`Availability of Standards and Conformance Evidence
`
`8.2.1 Open Specification and Standardization
`8.2.2 Conformance and Jnteroperability Testing
`8.2.3 Protocol Design Correctness
`
`8.3
`8.4
`8.5
`
`Design Margin
`Configuration Table Correctness and Performance Justification
`Network Monitoring and Test Equipment
`
`9.
`
`10.
`
`11.
`
`12.
`
`13.
`
`SECURlTY
`
`EVALUATION PROCESS
`
`SUMMARY
`
`REFERENCES
`
`GLOSSARY OF TERMS
`
`APPENDIX A-DATA NETWORK TECHNOLOGY AND ISSUES
`
`36
`
`37
`
`37
`37
`
`37
`38
`38
`
`39
`39
`41
`
`42
`
`43
`
`43
`
`44
`
`45
`
`v
`
`Exhibit 1320 Page 006 of 103
`
`

`
`LIST OFT ABLES
`
`Table
`
`Seven-Layer ISO OSI Model
`
`Page
`
`8
`
`vi
`
`Exhibit 1320 Page 007 of 103
`
`

`
`LIST OF ABBREVTA TIONS AND ACRONYMS
`
`AC
`ARINC
`BER
`BGP
`CAN
`CAST
`CCA
`CFR
`COTS
`CRC
`CSMA/CD
`de
`DMA
`EDAC
`FAA
`FCS
`FIFO
`FME/\
`FMECA
`FTA
`llD
`HIRF
`IC
`IEEE
`ISI
`ISO
`LLC
`MAC
`MTL-STD
`NACK
`OSl
`PLL
`PSS/\
`RAM
`RF
`S/\E
`SERDES
`SEU
`SNR
`sos
`TCP/IP
`TDMA
`TMR
`TTP/C
`
`Advisory Circular
`Aeronautical Radio, Incorporated
`Bit error rate
`Byzantine generals' problem
`Controller area network
`Certification Authorities Software Team
`Common cause analysis
`Code of Federal Regulations
`Commercial off-the-shelf
`Cyclic redundancy code
`Carrier Sense Multiple Access/Collision Detect
`direct current
`Direct memory access
`Error detection and correction
`Federal Aviation Administration
`Frame check sequence
`First-in, first-out
`failure modes and effects analysis
`Failure modes, effects, and criticality analysis
`Fault tree analysis
`Hamming distance
`J ligh-intcnsity radio frequency
`Integrated circuit
`Institute of Electrical and Electronic Engineers
`lntersymbol interference
`International Standards Organization
`Logical link control
`Media access control
`Military Standard
`Negative acknowledgements
`Open Systems Interconnect
`Phase-locked loop
`Preliminary system safety analysis
`Random access memory
`Radio frequency
`Society of Automotive Engineering
`Serial izcr/deserializer
`Single-event upset
`Signal-to-noise ratio
`Slightly-out-of-specification
`Transmission Control Protocol/Internet Protocol
`Time division multiple access
`Triple modular redundancy
`Time Trigger Protocoi/S/\E Class C
`
`vii/viii
`
`Exhibit 1320 Page 008 of 103
`
`

`
`EXECUTIVE SUMMARY
`
`Databus and data network technology continues to play an ever-increasing role in av iation digital
`electronics architectures throughout the range of aviation markets. The evolution of integrated
`modular aviation digital electronics architectures comprising multiple subsystems integrated into
`single and redundant data networks is increasing the influence of data networking. The
`criticality of data networks has previously led avionics manufacturers and aircraft original
`equipment manufacturers to design specific aerospace solutions to meet their requirements. In
`recent years, cost challenges have led to the adoption of commercial off-the-shelf (COTS)
`communication solutions in avionics. Although attractive from a cost perspective, the adoption
`of COTS presents certification issues, particularly as the complexity and increased leverage of
`technology continues to evolve.
`Subtleties may escape the system designer and leave
`dependability holes. An example is the interference of the Controller Area Network bit-error
`stuffing mechanism with message cyclic redundancy code coverage. COTS can be adopted as(cid:173)
`is, or with fixes added so it is a better fit for dependable avionics requirements, i.e., the
`adaptation of Ethernet to Aeronautical Radio, incorporated (ARJNC®) Part 7. Helping this trend
`is the arrival of "safety-critical COTS" in the marketplace, particularly in automobile and
`process-control areas. However, even with designed-for-purpose technology, it is necessary to
`ensure that the technology has d~pendability consistent with real-world requirements and
`redundancy management schemes.
`
`Development and evaluation of aviation digital electronics data networks that are suitable for
`safety-critical aviation digital electronics is a complex subject area.
`It requires detailed
`knowledge of communications systems, aviation communication and application requirements,
`mechanisms for creating dependable architectures, certification expectations, and assurance
`strategies. It is also important to note that, with correct architectural mitigation, almost any data
`network may be used in a certified system. For example, a layer of fault tolerance can be placed
`above the network to fix any of its shortcomings.
`
`The objective of this Handbook is to provide criteria for evaluating data network techno logy for
`use in safety-critical applications. However, this should not be taken to mean that these criteria
`can be used to rank data networks in a scale of absolute goodness, independent of the avionics
`systems in which they are employed. Because the operation of a data network is so entangled
`with the avionics system it supports, it is not possible to make an evaluation of a data network on
`its own. The goal is to create a sufficient breadth of criteria that can be used to evaluate the
`widest range of data networks with respect to the avionics systems in which they may be
`employed.
`
`This Handbook builds on previous documents in this area, particularly the Certification
`Authorities Software Team
`(CAST-16) position paper, "Databus Evaluation Criteria,"
`"Handbook for Ethemet-Based Aviation Databuses: Certification and Design Considerations,"
`and Advisory Circular 20-J 56, "Aviation Databus Assurance."
`
`This Handbook includes a structured list of issues and criteria related to evaluating data network
`technologies for digital electronics applications. Many of these issues and criteria are
`overlooked or are underappreciated by many oftoday's digital electTonics designers.
`
`ix
`
`Exhibit 1320 Page 009 of 103
`
`

`
`The material contained in this Handbook is part of the work done for the Databus Evaluation
`Criteria research project. This project was carried out in collaboration with Honeywell
`Laboratories, Minneapolis, MN; Carnegie Mellon University, Pittsburgh, PA; and Certification
`The funding was ,provided by
`the Federal Aviation
`Services Inc., Eastsound, WA.
`Administration.
`
`X
`
`Exhibit 1320 Page 010 of 103
`
`

`
`1. LNTRODUCTION.
`
`The goal of this Handbook was to document objective evaluation criteria for data networks to be
`used in aviation products. Of particular interest are digital electronics applications that are safety
`critical. The evaluation of databus and networking technology is not a simple matter. lt requires
`a detailed review and analysis of the lowest-level implementation charc:~cteristics of the selected
`technology together with the ability to map significant behaviors and failures to their
`architectural relevance. Avionics data networks arc becoming more complex. They are evolving
`from half-duplex links Aeronautical Radio, Incorporated (ARlNC®) 429 to full-duplex buses
`with multiple transmitters. Single master buses (ARlNC 429, Military Standard (MIL-STD)
`1553) are becoming networks with multiple masters or peer-based networks where effectively all
`nodes are masters (ARINC 664). These data networks are increasing their complexity by
`offering more features than in the past, for example, multiple classes of service. In the drive to
`reduce cost and weight, more integrated networks are shouldering a larger responsibility for
`correct system operation and avionics system fault containment.
`
`For the purposes of this Handbook, the term "evaluation criteria, means the standards on which a
`judgment can be made regarding the suitability of a data network for use in digital electronics
`systems, given the characteristics or features of the data network that may have an impact on
`system safety. One cannot definitively say that a particular characteristic or feature would have a
`safety impact, because the archltecture in which the network is used may be insensitive to (e.g.,
`may not need) the particular characteristic or feature that would be a problem for other
`architectures. Thus, this Handbook will describe all the evaluation criteria that need to be
`considered, regardless of any particular architecture. The system designer and evaluators then
`must determine whether a particular evaluation criterion is applicable to the data network being
`evaluated and the system being designed.
`
`This Handbook is not intended to provide a "go/no-go" checklist for justifying any particular
`data network technology since such a decision is very dependent on how a particular technology
`is used within an application. Therefore, if the evaluation of a network's suitabi lity for a
`particular avionics system is unsure or unsatisfactory, the system designer has three options (only
`the first of which could be considered a go/no-go type of decision):
`
`•
`•
`•
`
`Select a different data network
`Alter the data network design or implementation to overcome shottcomings
`Change the system design to accommodate the shortcoming(s)
`
`Instead of a simple checklist, this Handbook provides a set of criteria with ancillary questions
`that form a framework for a data network technology, e.g., examination of conscience, that can
`be used to bridge the gaps between a data network technology's behaviors and the system-safety
`assumptions that underpin the top-level safety case. This is in contrast to a simplistic go/no-go
`judgment of the data network technology evaluated outside of any context of a digital electronics
`architecture in which it may be used.
`
`1.1 ORGANIZATION.
`
`Section 1 gives an introduction that provides a rationale for creating this Handbook.
`
`Exhibit 1320 Page 011 of 103
`
`

`
`Section 2 describes some aspects of the environment surrounding the evaluation of a data
`network.
`
`Sections 3 through 9 of this Handbook present a discussion of data network technology attributes
`that must be considered when evaluating the technology within aviation digital electronics
`systems. This information is organized in relation to the hierarchies ol communication stack
`models (e.g., the International Standards Organization (ISO) Open Systems lnterconnect (OSI)
`model) for evaluation criteria that fit well with these models (sections 3 through 6) and by
`themes of special interest that require attention in the system design and deployment (sections 7
`through 9).
`
`Organizing the criteria along a communication stack model should make them easier to fmd and
`to correlate against communication network description documents, which are often organized in
`this way. However, a pure communication stack model approach misses essential attributes of
`data network design. Therefore, it is these areas of special interest (sections 7 through 9) that are
`most likely to be missed.
`
`Sections 3 through 9 include criteria paragraphs that are numbered sequentially according to
`their relation to the protocol stack hierarchy. These paragraphs are inserted at the end of sections
`where the introduction of the criteria is appropriate. Each criterion is formatted in bold font
`beginning with a criterion number followed by a short title, and the main criterion question or
`statement. An optional paragraph of ancillary questions may immediately follow a criteria
`paragraph. These questions are intended to help the reader evaluate the criterion by calling
`attention to various aspects of the network design.
`
`Note that criterion 2 is an exception to the standard for numbering criteria paragraphs
`sequentially. While the criterion 2 is numbered appropriately for its relationship to the protocol
`stack hierarchy, for the purpose of this document, it is placed where it will be best understood
`(section 4.2) after line-level encoding, has been explained.
`
`Section 10 suggests an evaluation process using this Handbook.
`
`Section 11 provides a summary.
`
`Section 12 I ists the references.
`
`Section 13 provides a list of the technical terms used throughout this Handbook.
`
`Appendix A provides additional information on data network technology and its issues.
`
`1.2 BACKGROUND.
`
`From a list of data network technology behaviors and beginning with the Certification
`Authorities Software Team (CAST-16) position paper, "Databus Evaluation Criteria" f 11;
`"Handbook for Ethernet-Based Aviation Databuses: Certification and Design Considerations"
`[2]; and Advisory Circular (AC) 20-156, "Aviation Databus Assurance" l3) as departure points,
`an examination was made of how communications primitives and services can be leveraged at
`
`2
`
`Exhibit 1320 Page 012 of 103
`
`

`
`the application level, and what impacts the behaviors may introduce with respect to certification.
`The "Data Network Evaluation Criteria Report" [4] also serves as a source for this Handbook.
`
`1.2.1 Data Network Evaluation Relative to a System Safety Process.
`
`The sheer variety of network and databus technology makes it difficult to characterize generic
`attributes that can be used for a set of all-encompassing evaluation criteria. The details of the
`implementation of these networks determine their characteristics; they may be serial, parallel,
`synchronous, asynchronous, external, internal, intersystem or intrasystem wired, or wireless, etc.
`In addition, the potential failure behavior of the databus or network technology may be mitigated
`at the system architecture level, for example, by employing multiple independent data paths,
`design dissimilarity, or enhanced end-to-end integrity mechanisms above the core network
`behavior. For these reasons, a bottom-up go/no-go checklist is very difficult to elicit at the
`network level. Instead, a holistic view of the entire system is required to ensure that the use of
`the network technology is sufficient to meet the system-level functional responsibility and safety
`assumptions. Therefore, databus and network technology have traditionally been evaluated on a
`case-by-case basis against federal aviation regulation Title 14 Code of Federal Regulations
`(14 CFR) (Aeronautics and Space, Airworthiness Standards) XX.l309 (the safety-related
`regulations) and 14 CFR XX.130 1 (the intended function-related regulations) with a detailed
`review of the implementation mechanisms. Pe1tinent regulations related to this research, and
`adopted and enforced by the Federal Aviation Administration (FAA) are contained in 14 CFR
`Chapter I Parts l-199, FAA, Department of Transportation) Part XX (identified below), Subpart
`F (Equipment), Section XX.l301 (Function and Installation) and Section XX.1309 (Equipment,
`systems, and instaJiations), and are identified as follows:
`
`•
`
`•
`
`•
`
`•
`
`•
`
`Part 23- Small Airplanes (Normal, Utility, Acrobatic, and Commuter Category
`Airplanes)
`
`Part 25-Transport Category Airplanes
`
`Part 27-Small Helicopters (Normal Category Rotorcraft)
`
`Part 29-Large Helicopters (Transport Category Rotorcraft)
`
`Part 33-Aircraft Engines
`
`In addition, 14 CFR 33.28 (Aircraft Engines, Electrical and Electronic Engine Control Systems)
`also applies. This process is initially top-down, focusing on functions at the aircraft level that are
`enumerated in a function list.
`
`The hazards associated with the functional failure conditions are determined for each function at
`the aircraft level. Note that at the initial stages of the process, designers and evaluators may not
`know how these functions will be allocated to subsystems. While it can be the common cause
`for failures in multiple functions, the bus or network has not traditionally been viewed as an
`airplane-level function, rather, it is a tier design choice for how the functions are provided, so at
`this point, there is no impact. One or more candidate system architectmes for aircraft-level
`
`3
`
`Exhibit 1320 Page 013 of 103
`
`

`
`functions are proposed. The system could be a single processing module (analog or digital) with
`a number of inputs or outputs fed directly to the box, or a single box for each function (analog or
`digital), or any of a number of alternative architectures. This architecture then terms the basis
`for an aircraft-level fault tree that demonstrates how failure conditions will flow through the
`architecture.
`
`At this stage, it is not uncommon to sta1t looking at common cause analysis (CCA). CCA
`consists of three components: (I) particular risk analysis (e.g., lightning), (2) common-mode
`analysis (e.g., all boxes receive cooling from a single source or data from a shared network), and
`(3) zonal analysis (e.g., a fire in the wheel well damages wires that pass through the area but are
`not related to any equipment in the wheel well), at the architecture level (for example, consider
`the implications of the two mentioned architectures). As the architecture is refined, an airplane(cid:173)
`level network may be derived; this will need to be considered as part of the system fault tree
`analysis (FTA). This process continues iteratively until a detailed component (i.e., line
`replaceable unit) level design emerges. This iterative top-down process is captured by a
`preliminary system safety analysis (PSSA), system and subsystem fault trees, and revisitation of
`the common cause and zonal analysis as appropriate. The lower levels of the fault tree will
`contain a number of different faults that can be traced to aircraft-level failure conditions. As the
`architecture is continuously refined, the use of databuses and network technology can appear at
`any level and feed into the continuously evolving PSSA. When a preliminary complete design
`emerges, then a bottom-up approach, called a failure modes and effects analysis (FMEA) or a
`failure modes, effects, and criticality analysis (FMECA), is instituted on the actual design
`looking at specific failures of components or group of components and their contribution to the
`aircraft hazards. A failure condition would be phrased as "loss of all braking" due to a hardware
`failure (unspecified), and analysis would be conducted to determine all possible failures that
`could cause the failure condition. The FMEA would start with something like the failure of a
`power supply and trace it to a system effect. Ideally, the top level of an FMEA or FMECA can
`be identified with the faults from one or more fault trees. Databuses and network technology
`services may, therefore, appear in any level ofthe system design and are required to be analyzed
`fi·om both the bottom-up (FMEA/FMECA) and top-down (FTA/PSSA, as well as the CCA).
`When the iterative process is finished, the safety results are documented in the system-safety
`analysis, including the summaries of the FMEA/FMECAs and the CCA.
`
`For this process to work effectively, it is paramount that the impact of the behavior and potential
`failure of the databus and network technology is adequately captured and represented in the
`FT A. For low-complexity network and data bus teclmology, the process above is relatively
`straightforward. In such cases, the network services assumed by the upper levels ofthe system
`behavior are simple and restricted to point-to-point communication primitives only (for example,
`those concerned with the loss, delay, or corruption of information restricted to a few nodes).
`However, as silicon
`integration
`increases (enabled by continually decreasing process
`geometries), the failure modes of integrated devices are getting considerably more difficult to
`lienee, even in the case of simple communication services, great care is required to
`bound.
`ensure that the failure mechanisms and assumptions are suitably captured.
`In addition, as
`networking technology has advanced, a number of additional services have been implemented at
`the network
`level
`(for example, acknowledgement, message agreement, global
`time
`synchronization, system mode change distribution, fault diagnosis, power distribution, etc.). The
`
`4
`
`Exhibit 1320 Page 014 of 103
`
`

`
`system-level impact of such services may be significant, and in many cases, the databus or
`network may form the intelligence backbone of the system or entire aircraft. In these cases, a
`more detailed analysis of network behavior and system logic and assumptions is required. For
`example, if message agreement or interactive consistency is leveraged by applications operating
`above the network infrastructure to implement active replication strategies (for example, replica
`determinism for triple-modular replication), the justification of the application-level behavior
`needs to address implications of network failures or transient upsets that may affect the coverage
`of such strategies in the event of a fault or external system upset.
`
`1.2.2 The CAST-16 Position Paper.
`
`The CAST-16 position paper, "Databus Evaluation Criteria," [1] was published in February 2003
`with the stated purpose of documenting "criteria that should be considered by databus
`manufacturers, aircraft applicants, and certification authorities when developing, selecting,
`integrating, or approving a databus technology in the context of an aircraft project". 1 A CAST
`position paper expresses regulatory concern about technical and safety issues. These concerns
`have been captured in the August 2006 publication of AC 20-156, Aviation Databus Assurance,
`which is described in section 1.2.4.
`
`f.2.3 Ethernet Handbook.
`
`In September 2004, the "Handbook for Ethernet-Based Aviation Databuses: Certification and
`Design Considerations" [2] was published. Its purpose was "to provide the network designer and
`developer with some guidelines to develop an Ethernet-basea databus framework deployable in
`certifiable avionics systems."
`
`This Ethernet Handbook builds on the CAST-16 position paper and adds guidelines specific for
`Ethernet-based data networks. These guidelines were not developed solely for the Institute of
`Electrical and Electronic Engineers (IEEE) 802.3 standards, but also for aviation digital
`electronics-specific Ethernet derivatives.
`
`The IEEE 802.3 standards constitute a wide variety of data networks. Speeds range from the
`1990 version that operated at a maximum of ten megabits per second to ten gigabits per second
`at the time of this Handbook's publication. It can be expected that even higher-speed versions
`will be created in the future. The physical line symbol coding includes Manchester, 4b/5b,
`8b/l Ob, and several lesser used encoding schemes. The topologies include buses and stars.
`There are a number of Ethernet variants, with the simplest using a total of two wires, and the
`most complex using eight wires per node. Fiber-optic versions of Ethernet use two fibers for
`each node. The media access control (MAC) mechanisms include Carrier Sense Multiple
`Access/Collision Detect (CSMA/CD), which is primarily used for buses and in switch-based
`mechanisms used for stars.
`
`It is important to note that all CAST papers include the following disclaimer: "This position paper has been
`coordinated among the software specialists of certification authorities from the United States, Europe, and
`Canada. However, it does not constitute official policy or guidance from any of the authorities. This document is
`provided for educa6onal and informational purposes only and should be discussed with the appropriate
`certification authority when considering for actual projects."
`
`5
`
`Exhibit 1320 Page 015 of 103
`
`

`
`Adding to this wide variation of JEEE standard, Ethernets are Ethernet derivatives designed
`specifically for aviation digital electronics. These include ARJNC 646 Ethernet Local Area
`Network, ARINC 664 Aircraft Data Network, and the Avionics Standard Communications Bus,
`Version D. These derivatives range from simple adaptations to the aviation digital electronics
`rugged environment to whole-scale usurping of the MAC protocols with protocols that provide
`varying degrees of increased media access determinism.
`(See section 2.3.1 for a detailed
`discussion of determinism.)
`
`While the Ethernet Handbook covers a wide variety of Ethernet derivatives with guidelines that
`are more detailed than the CAST -16 position paper, it covers only a small fraction of the possible
`data networks that can be used for aviation digital electronics.
`
`1.2.4 Advisory Circu lar 20- L 56 Aviation Data bus Assurance.
`
`AC 20-156 was published in August 2006, which follows very closely to the CAST-16 position
`paper. Thus, it does not include specific and detailed criteria. 1\.C 20-156 describes a means to
`gain r AA approval of an aviation data network; wherein the means show that the data network
`design performs its intended function and satisfies the applicable airworthiness requirements
`when installed on an aircraft or aircraft engine. This AC is not mandatory and docs not
`constitute a regulation. Jt describes an acceptable means, but is not the only means, by which a
`data network can be successfully included in a certified aircraft or aircraft engine.
`
`AC 20-156 calls out eight criteria categories based largely on those created by the CAST -16
`paper. Within each category, specific criteria were enumerated. The eight categories and
`number of criteria in each are:
`
`•
`•
`•
`•
`•
`•
`•
`•
`
`Safety-7 criteria
`Data Integrity-I 0 criteria
`Databus Performance-12 criteria
`Software and Hardware Assurance- 3 criteria
`Electromagnetic Compatibility--4 criteria
`Verification and Validation-) 0 criteria
`Configuration Management-7 criteria
`Security Assurance-2 criteria
`
`1 .3 PURPOSE.
`
`This I land book is intended to facilitate the overall certification process for aircraft or aircraft
`It builds on the
`engines that employ digital electronics systems containing data networks.
`previous work described above, by providing specific and detailed criteria for evaluating a wide
`range of data network technologies and components with respect to the possible adverse impacts
`on cert