Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Laboratories, Minneapolis, MN; Carnegie Mellon University, Pittsburgh, PA; and Certification. Services Inc., Eastsound, WA. The funding was provided by the ...
Typology: Exams
1 / 103
This page cannot be seen from the preview
Don't miss anything!
Air Traffic Organization NextGen & Operations Planning Office of Research and Technology Development Washington, DC 20591
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
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).
Page
vi
Table Page
1 Seven-Layer ISO OSI Model 8
AC Advisory Circular ARINC Aeronautical Radio, Incorporated BER Bit error rate BGP Byzantine generals’ problem CAN Controller area network CAST Certification Authorities Software Team CCA Common cause analysis CFR Code of Federal Regulations COTS Commercial off-the-shelf CRC Cyclic redundancy code CSMA/CD Carrier Sense Multiple Access/Collision Detect dc direct current DMA Direct memory access EDAC Error detection and correction FAA Federal Aviation Administration FCS Frame check sequence FIFO First-in, first-out FMEA Failure modes and effects analysis FMECA Failure modes, effects, and criticality analysis FTA Fault tree analysis HD Hamming distance HIRF High-intensity radio frequency IC Integrated circuit IEEE Institute of Electrical and Electronic Engineers ISI Intersymbol interference ISO International Standards Organization LLC Logical link control MAC Media access control MIL-STD Military Standard NACK Negative acknowledgements OSI Open Systems Interconnect PLL Phase-locked loop PSSA Preliminary system safety analysis RAM Random access memory RF Radio frequency SAE Society of Automotive Engineering SERDES Serializer/deserializer SEU Single-event upset SNR Signal-to-noise ratio SOS Slightly-out-of-specification TCP/IP Transmission Control Protocol/Internet Protocol TDMA Time division multiple access TMR Triple modular redundancy TTP/C Time Trigger Protocol/SAE Class C
vii/viii
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
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 significant 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)
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 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 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):
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.
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.1309 (the safety-related regulations) and 14 CFR XX.1301 (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 1-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:
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 architectures for aircraft-level
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 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 uncommon to start looking at common cause analysis (CCA). CCA consists of three components: (1) 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 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 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 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 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 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 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 implemented at the network level (for example, acknowledgement, message agreement, global time synchronization, system mode change distribution, fault diagnosis, power distribution, etc.). The
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 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 Circular 20-156 Aviation Databus 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. 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 certified aircraft or aircraft engine.
AC 20-156 calls out eight criteria categories based largely on those created by the CAST- paper. Within each category, specific criteria were enumerated. The eight categories and number of criteria in each are:
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 networks. 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
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 depth of criteria as possible. To partially mitigate the problem of having an overwhelming set of criteria, this Handbook presents the criteria on two levels. The higher level is presented in the body of the Handbook with much more detailed discussions included in appendix A. Someone still needs to determine what criteria are applicable to what data network, a task which is too varied to be prescribed in the confines of this Handbook.
Certifiability of a data network means that, if the data network is deployed in aviation digital electronics and complies with all applicable regulations and guidance, one cannot introduce any unacceptable risk to the aircraft as determined by the system safety analysis. Note that this is different from the notion of the product adding quality to the system. An aviation digital electronics component, such as the data network, may add quality. This Handbook does not deal with added quality; rather, it focuses on identifying and preventing aspects of the product that detract from the factors impacting certifiability. Particular attention is given to issues that are generally overlooked or underappreciated in the industry.
This Handbook presents and describes criteria that should be considered by data network manufacturers, aircraft applicants, and certification authorities when developing, selecting, integrating, or approving a data network technology or components in the context of an aircraft project.
1.4 SCOPE.
1.4.1 System Network Role.
The evaluation criteria described in this Handbook were selected to help in the creation or selection of safety-critical aviation digital electronics data networks. The data networks that are safety critical tend to be system data networks (i.e., data networks that connect together a number of subsystems) or data networks that connect together the redundant elements of a safety-critical subsystem. These data networks generally have been “box-to-box” rather than backplane memory or peripheral extension buses, such as the peripheral component interconnect. The latter are used to connect together cards within a box that implement a single function or form a single fault containment zone within the redundancy set (i.e., one replicant).
A few networks, such as SAFEbus, are actually system buses implemented in a backplane. The role of the network is what is important, not where or how it is implemented. Backplane system networks can be differentiated from simple extension backplanes by the fact that they have a higher level of safety criticality or that they may connect together multiple subsystems rather than just the components of one subsystem.
The widely used Department of Defense Advanced Research Projects Agency Network TCP/IP suite does not have an official stack description document. But it is known to have four or five layers, with the bottom three layers generally corresponding to the bottom three layers of the OSI stack.
For the embedded real-time systems used in the vast majority of safety-critical aviation digital electronics, models with a reduced number of layers have been used to provide lower complexity, latency, and overhead.
The lower layers of the stacks deal with the communication media and the hardware connected to it. The higher layers of the stacks represent functionality that is progressively abstracted further away from the hardware. When developing selection criteria for data networks that will be used in safety-critical systems, a question naturally arises as to which layers need to be evaluated. This question is equivalent to asking: What layers can affect the dependability of the overall communication system? This will depend on where the designers have implemented mitigation means, the type of failures that can be realized at a given layer, and the effect on the system safety analysis. In general, the highest layer, where communication dependability is considered, is usually identified as the transport (or equivalent) layer. Some networks handle dependability issues partly or entirely within layers below the transport layer, while others deal with them at the application layer that interfaces with the transport layer. In many cases, multiple layers will be needed to provide an acceptable dependability argument. Communication network hardware typically implements stack layers below the transport layer, and many of the networks proposed for aviation digital electronics systems only define these lower layers. However, some of these hardware devices also provide special application services that support system fault tolerance.
In general, the scope of the evaluation criteria described in this Handbook extends from the lowest stack layer, up through the dependability features of the transport layer or to the highest layer that is part of the network standard (or definition, if the network is not a standard), if that network does not include functionality up to the dependability features of the transport layer. Safety-critical embedded real-time systems often require services not included in generic protocol stack models, such as a time synchronization service. These special services will be included within the scope of these criteria.
1.4.3 Developmental Time Horizon.
The evaluation criteria were chosen so future data network communication technologies, as well as current technologies, can be evaluated.
When evaluating a data network for a particular aviation digital electronics application, one must begin by establishing the requirements for that data network. The requirements placed on a data network are highly dependent on the aviation digital electronics architecture that will employ the network.
To develop requirements for an avionics data network, the results from the following tasks should be captured:
Such a top-down examination of network use is needed to establish a context for the detailed analysis of the network lower-level properties and behaviors presented in the following sections. Therefore, without this system context, the justification of databus and network suitability or unsuitability is impossible to determine.
2.2 MULTIPLE-REQUIREMENT ENGINEERING TRADES.
As with any complex technology, the selection (or creation) of data network technologies requires the evaluation of how well a particular technology alternative meets a large number of requirements, many of which are contradictory. What is more important: size, weight, power, cost, bandwidth, latency, availability, integrity,...? Technology trades must consider all requirements simultaneously. Therefore, the relative importance or weighting of these requirements must be established. After the relative importance rankings of the requirements
