DOT/FAA/AR-09/24
`
`Air Traffìc Organization
`NextGen & Operations Planning
`Offlce of Research and
`Technology Development
`Washington, DC 20591
`
`Data Network Evaluation
`Griteria Handbook
`
`June 2009
`
`Final Report
`
`This document is available to the U.S. public
`through the National Technical lnformation
`Services (NTIS), Springfield, Virginia 22161.
`
`è
`
`U.S. Depafiment of Transportation
`Federal Aviation Administration
`
`Exhibit 1232 Page 001 of 103
`
`

`

`NOTICE
`This document is disseminated under the sponsorship of the U.S.
`Department of Transpoftation 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 repoft 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 1232 Page 002 of 103
`
`

`

`2 GovernmentAccess¡on No.
`
`Technical
`3 Recipient's Catalog No
`
`rt Documentation
`
`'1. Report No
`
`DOT/FAA/AR-09/24
`4 Title and Subtitle
`
`DATA NETWORK EVALUATION CRITERIA HANDBOOK
`
`7 Autho(s)
`
`5. Reporl Date
`
`June 2009
`6 Performing OrganÌzation Code
`
`B Performing Organ¡zat¡on Report No
`
`Kevin Driscoll, Brendan Hall, Phil Koopman, Justin Ray, and Mike DeWalt
`9. Peforming Organization Name and Address
`
`10 Work Unil No, (l RAIS)
`
`Honeywell International, Inc.
`3660 Technology Drive
`Minneapolis, MN 55418
`12, Sponsoring Agency Name and Address
`
`U.S. Deparlment of Transportation
`Federal Aviation Administrati on
`Air Traffic Organization NextGen & Operations Planning
`Office of Research and Technology Development
`'Washington, DC2059l
`
`15. Supplementary Notes
`
`11. Contract or Grant No.
`
`DTFACT-05-C-OOOO2
`'13 Type of Report and Per¡od Covered
`
`14 Sponsor¡ng Agency Code
`AIR.120
`
`The Federal Aviation Administration Airport and Airclaft SafeW R&D Division COTR was Charles Kilgore
`16. Abstrâct
`
`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 ceÍification of aircraft or aircfaft 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. of aircraft engine certification
`process. It focuses on identifling aspects of the technologies and component implementations that ultimately may have an
`adverse impact on the approval within the certification of an aircraft. Particular attention is given to issues lhaf 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
`
`Databus, Network, Certification, Criteria, COTS
`
`l8 D¡stribut¡on Statement
`This document is available to the U.S. public through the
`National Technical Information Service (NTIS), Springfield,
`Ytrsinia2216l.
`20 Secur¡ty Class¡f (of this page)
`Unclassified
`
`21. No ofPages
`103
`
`22 Price
`
`Reproduction of completed page author¡zed
`
`19 Security Classif (of this reporl)
`Unclassified
`
`Form DOT F 1700.7 ß-tz)
`
`Exhibit 1232 Page 003 of 103
`
`

`

`Page
`
`IX
`
`I 2 3 5 5 6 6 7 7 B 9
`
`l0
`
`l0
`10
`1t
`
`t2
`I3
`
`13
`
`l3
`t4
`l5
`l5
`l6
`
`16
`
`t7
`18
`t8
`19
`
`TABLE OF CONTENTS
`
`EXECUTIVE SUMMARY
`I.
`
`INTRODUCTION
`
`l.l
`r.2
`
`OrganizaTion
`Background
`
`1.2.1
`1.2.2
`1.2.3
`1.2.4
`
`Data Network Evaluation Relative to a System Safety Process
`The CAST-I6 Position Paper
`Ethernet Handbook
`Advisory Circular 20-156 Aviation Databus Assurance
`
`1.3
`1.4
`
`Purpose
`Scope
`
`System Network Role
`1.4.1
`Protocol Stack
`1.4.2
`Developmental Tirne Horizon
`1.4.3
`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
`
`Environment
`3.1
`Probability of Bit Errors
`3.2
`Probability of Electrical Component Failures
`3.3
`Electrical lsolation Properties
`3.4
`Physical Composability
`3.5
`4. DATA LINK LAYER
`
`4.1
`4.2
`4.3
`4.4
`
`The MAC
`Line-Level Encoding
`Message Formating (Framing)
`Error Detection
`
`lll
`
`Exhibit 1232 Page 004 of 103
`
`

`

`Protocol Violation Error Detection
`4.4.r
`19
`l9
`Parity and Frame Check Sequences
`4.4.2
`Interactions Between Line-Level Encoding and Error Detection
`4.4,3
`19
`5. NETWORK LAYER, TRANSPORT LAYER, AND NETWORK MANAGEMENT 20
`5.1 Network Vulnerability to Addressing Information Failure
`5.2 Network Vulnerability to Flow Failure
`5.3 Impact of Intermediate Stages
`
`20
`2t
`2T
`
`5.3.1 Vulnerability to Intermediate-Stage Failure
`5.3.2 Vulnerability 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
`
`Client Buffer Queue Management
`6.1.1
`Buffer Management Partitioning
`6.1.2
`B uffer Management Perform ance C on s iderati on s
`6.1.3
`6.2 Support for Application Layer Redundancy
`
`Support for Active Replication
`6.2.r
`Support for Passive Replication
`6.2.2
`Support for Increased Integrity
`6.2.3
`Support for Robust Partitioning
`6.2.4
`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 Detecti on
`Voting, Selection, or Agreement Services and Redundancy Management
`
`IV
`
`22
`22
`
`z3
`23
`24
`25
`26
`27
`
`27
`
`28
`
`28
`28
`28
`
`29
`
`29
`30
`30
`3l
`
`3l
`
`32
`
`32
`32
`JJ
`34
`34
`35
`35
`
`Exhibit 1232 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
`8.2.2
`8.2.3
`
`Open Specifìcation and Standardization
`Conformance and Interoperability Testing
`Protocol Design Correctness
`
`8.3
`8.4
`8.5
`
`Design Margin
`C onfi guration Tab le Correctness and Performance Justi fication
`Network Monitoring and Test Equipment
`
`9.
`SECURITY
`10. EVALUATION PROCESS
`11. SUMMARY
`12. REFERENCES
`13. GLOSSARY OF TERMS
`
`APPENDIX A-DATA NETWORK TECHNOLOGY AND ISSUES
`
`36
`
`37
`
`37
`37
`
`3t
`38
`38
`
`39
`39
`4l
`
`42
`
`43
`
`43
`
`44
`
`45
`
`v
`
`Exhibit 1232 Page 006 of 103
`
`

`

`LIST OF TABLES
`
`Table
`1
`
`Seven-Layer ISO OSI Model
`
`Page
`
`8
`
`VI
`
`Exhibit 1232 Page 007 of 103
`
`

`

`LIST OF ABBREVIATIONS AND ACRONYMS
`
`AC
`ARINC
`BER
`BGP
`CAN
`CAST
`CCA
`CFR
`COTS
`CRC
`CSMA/CD
`dc
`DMA
`EDAC
`FAA
`FCS
`FIFO
`FMEA
`FMECA
`FTA
`HD
`HIRF
`IC
`IEEE
`ISI
`ISO
`LLC
`MAC
`MIL-STD
`NACK
`OSI
`PLL
`PSSA
`RAM
`RF
`SAE
`SERDES
`SEU
`SNR
`SOS
`TCP/IP
`TDMA
`TMR
`TTP/C
`
`Advisory Circular
`Aeronautical Radio, Incorporated
`Bit error rate
`By zantine generals' problem
`Controller area network
`Certifi cation 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 Admin istration
`Frame check sequence
`First-in, first-out
`Failure modes and effects analysis
`Failure modes, effects, and criticality analysis
`Fault tree analysis
`Hamming distance
`High-intensity radio frequency
`Integrated circuit
`Institute of Electrical and Electronic Engineers
`Intersymbol interference
`International Standards Or ganization
`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
`S erial izerldeserializer
`Single-event upset
`Signal-to-noise ratio
`S I i ghtly-out-of- sp eci fi cation
`Transmission Control Protocol/Internet Protocol
`Time division multiple access
`Triple modular redundancy
`Time Trigger Protocol/SAE Class C
`
`vii/viii
`
`Exhibit 1232 Page 008 of 103
`
`

`

`EXECUTIVE SUMMARY
`
`Databus and data network technology continues to play an ever-increasing role in aviation 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 daf.a 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 atlractive 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-
`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 (ARINC@) 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 dependability 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 irnportant to note that, with correct architectural mitigation, almost any da|a
`network may be used in a certified system. For example, a layer of fault tolerance can be placed
`above the nefwork to fix any of its shortcomings.
`
`The objective of this Handbook is to provide criteria for evaluating data network technology 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 ofabsolute goodness, independent ofthe 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 Ethernet-Based Aviation Databuses: Certification and Design Considerations,"
`and Advisory Circular 20-156, "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 of today's digital electronics designers.
`
`IX
`
`Exhibit 1232 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
`Services Inc., Eastsound, WA. The funding was provided by the Federal Aviation
`Administration.
`
`X
`
`Exhibit 1232 Page 010 of 103
`
`

`

`I. INTRODUCTION.
`
`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. It requires
`a detailed review and analysis of the lowest-level implementation characteristics of the selected
`technology together with the ability to map signif,rcant behaviors and failures to their
`architectural relevance. Avionics data networks are becoming more complex. They are evolving
`from half-duplex links Aeronautical Radio, Incorporated (ARINC@) 429 to full-duplex buses
`with multiple transmitters. Single master buses (ARINC 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 cornplexity 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 architecture 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 plovide a "go/no-go" checklist for justiSzing 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 suitability 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 shortcomings
`Change the system design to accommodate the shortcoming(s)
`
`a a a
`
`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.E., 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.
`
`1
`
`Exhibit 1232 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
`systenrs. This information is organized in relation to the hierarchies cf communication stack
`models (e.g., the International Standards Organizafion (ISO) Open Systems Interconnect (OSI)
`rnodel) 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 find 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) fhaf 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 ofsections
`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
`statenrent. 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 l0 suggests an evaluation process using this Handbook.
`
`Section 1l provides a summary.
`
`Section 12 lists 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 BACKGROLTND.
`From a list of data network technology behaviors and beginning with the Certification
`Authorities Software Team (CAST-16) position paper, "Databus Evaluation Criteria" [l];
`"Handbook for Ethernet-Based Aviation Databuses: Certification and Design Considerations"
`l2l; and Advisory Circular (AC) 20-156, "Aviation Databus Assurance" [3] as departure points,
`an examination was made of how communications primitives and services can be leveraged at
`
`2
`
`Exhibit 1232 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.I DafaNetwork 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
`(14CFR) (Aeronautics and Space, Airworthiness Standards) XX,1309 (the safety-related
`regulations) and 14 CFR XX.l301 (the intended function-related regulations) with a detailed
`review of the implementation mechanisms. Pertinent regulations related to this research, and
`adopted and enforced by the Federal Aviation Administration (FAA) are contained in 14 CFR
`Chapter I Parts I-199, FAA, Department of Transportation) Part XX (identified below), Subpart
`F (Equipment), Section XX.1301 (Function and Installation) and Section XX.1309 (Equipment,
`systems, and installations), and are identified as follows:
`
`a
`
`a
`
`a
`
`a
`
`a
`
`Part 23-Small Airplanes (Normal, Utility, Acrobatic, and Commuter Category
`Airplanes)
`
`P art 25-1 ransport Category Airpl anes
`
`P art 27 -Small He I i copters (Norm al C ate gory Rotorcraft )
`e He I icopters (Transport C ate gory Rotorcraft )
`P ar| 29 -Larg
`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 fhatat 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 architectures for aircraft-level
`
`3
`
`Exhibit 1232 Page 013 of 103
`
`

`

`functions al'e 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 ally of a number of alternative architectures. This architecture then forms the basis
`for an aircraft-level fault tree that demonstrates how failure conditions will flow through the
`architecture.
`
`At this stage, it is not uncomÍron to staft looking at common cause analysis (CCA). CCA
`consists of three components: (l) 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-
`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 fa.ilures 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 of the system design and are required to be analyzed
`from 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 systern-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
`FTA. For low-complexity network and databus technology, the process above is relatively
`straightforward. In such cases, the network services assumed by the upper levels of the system
`behavior are simple and restricted to point-to-point communication primitives only (for example,
`those concerned with the loss, delay, or corruption of inforrnation restricted to a few nodes).
`However, as silicon integration increases (enabled by continually decreasing process
`geometries), the failure modès of integrated devices are getting considerably more difficult to
`bound. Hence, even in the case of simple communication services, great care is required to
`ensure that the failure mechanisms and assumptions are suitably captured. In addition, as
`networking technology has advanced, a number of additional services have been irnplemented at
`the network level (for example, acknowledgement, message agreement, global tirne
`synchronization, system mode change distribution, fault diagnosis, power distribution, etc.). The
`
`4
`
`Exhibit 1232 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 justifìcation of the application-level behavior
`needs to address implications of network failures or transient upsets that may affect the coverage
`ofsuch strategies in the event ofa 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".l 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.
`
`1.2.3 Ethernet Handbool<.
`
`In September 2004, the "Handbook for Ethernet-Based Aviation Databuses: Certification and
`Design Considerations" [2] was published. lts purpose was "to provide the network designer and
`developer with some guidelines to develop an Ethernet-based databus framework deployable in
`certifiable av ionics systems."
`
`This Ethernet Handbook builds on the CAST-16 position paper and adds guidelines specific for
`Ethernet-based data networks. These guidelines \vere 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 rnegabits 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,4bl5b,
`8b/10b, and several lesser used encoding schemes. The topologies include buses and stars.
`There are a nurnber 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.
`I lt 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 educational and informational purposes only and should be discussed with the appropriate
`certification authority when considering for actual projects."
`
`5
`
`Exhibit 1232 Page 015 of 103
`
`

`

`Adding to this wide variation of IEEE standard, Ethernets are Ethernet derivatives designed
`specifically for aviation digital electronics. These include ARINC 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
`'rarying degrees of increased rredia 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.
`
`L2.4 Advisorv Circular 20-156 Aviation Databus Assurance.
`
`AC 20-156 was published in August 2006, which follows very closely to the CAST-I6 position
`paper. Thus, it does not include specific and detailed criteria. AC 20-156 describes a means to
`gain FAA 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 does not
`constitute a regulation. It describes an acceptable means, but is not the only means, by which a
`data network can be successfully included in a ceftified aircraft or aircraft engine.
`
`AC 20-156 calls out eight criteria categories based largely on those created by the CAST-I6
`paper. Within each category, specifrc criteria were enumerated. The eight categories and
`number of criteria in each are:
`
`Safety-7 criteria
`Data Integrity-l 0 criteria
`Databus Performanc e-I2 criteri a
`Software and Hardware Assurance-3 criteria
`Electromagnetic Compatibility-+ criteria
`Verification and Validation-1 0 criteria
`C onfiguration Man agem ent-7 criteria
`S ecurity Assurance-2 criteria
`
`o a a a a a a a
`
`1,3 PURPOSE.
`
`This Handbook is intended to facilitate the overall certification process for aircraft or aircraft
`engines that employ digital electronics systems containing data nefworks. It builds on the
`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 certification due to their use.
`
`The characteristics of data networks are so varied that it is impossible to create a single set of
`detailed and specific criteria in which all the criteria are applicable to all data network
`
`6
`
`Exhibit 1232 Page 016 of 103
`
`

`

`technologies and components in all possible applications. Because of this extremely wide
`variation, creating a concise set of specific and detailed criteria for data networks is much more
`difficult than creating a similar set of criteria for microprocessors. The combination of
`extremely wide variation and detail leads to a set of criteria that can be overwhelming.
`
`However, for safety-critical systems, it is usually true that the accuracy of the details is essential.
`Therefore, this Handbook tries to include as much breadth and dept