航空电子全双工交换式以太网（AFDX，Avionic Full-Duplex Switched Ethernet)，是 ARINC664（part7）的一个特定实现，是一种用于航空电子领域的数据网络协议。该网络基于 IEEE 802.3 标准。
1、航空数据总线的历史
航空控制系统一般由一系列传感器组成，这些传感器读取环境或者内部的数据，一个航空系统需要执行某一确定的飞行相关的控制功能并且产生输出，例如控制执行机构执行方向舵或者襟翼的运动。这些部件之间总是需要相互连接，传统上，一组传感器和执行器连接到一个航空电子设备功能。航空数据总线如：ARINC-429和MIL-STD 1553就是用来达到这个目的的。
1.1、ARINC-429
ARINC-429 是一种专用与商用或运输飞行器的双线式数据总线，采用双绞线的形式，数据字长 32bit 并且绝大多数数据由单一的字组成。429 的 TX 和 RX 由分开的 ports 指定，信息传送速率 12.5Kbit/s 或 100Kbit/s，一根总线最多只可拥有 20 个 recivers。
1.2 、MIL-STD 1553
略。
2、IMA 需要新的通信能力
随着飞行器的发展，越来越多电子组件加入到航空控制系统中，例如飞行控制和导航系统提供飞行判断功能，其他的组件提供辅助服务对维持适航性不重要，但是减少了工作组的负担。大量的能力在增加，同样的增加了大量需要处理和展示出来的信息。
因此一种新的标准化的主平台出现了，IMA（Integrated Modular Avionic）出现了，同时它还非常简单：
- 使用一个通用计算平台提供计算能力；
- 使用标准化的传感器和执行器接口，并在单独的 I/O 板子上提供；
- 计算平台为航空电子应用提供一个实时操作系统（RTOS）和标准的接口（API）。
IMA 相较传统方式带来了许多优点。同时也需要一种新的网络基础设施。
3、AFDX，新一代的航空电子数据网络
AFDX 基于标准的 IEEE 802.3 10/100 Mbit 以太网硬件，数据包用 IP 和 UDP 封装，但有两个问题没有解决：
- 可靠的数据包转发；
- 可界定的转发延迟；
3.1、灵活的网络拓扑
正常的网络采用拓扑结构，拓扑结构上的每一个节点都是平等的，如果一个节点想要发送一个数据包给网络，但是媒体被占用了，发生了冲突，那么这个节点需要备份数据，并且再次尝试，直到发送成功或者超时。这种特性导致了无法预料的延迟，这在一个安全关键应用中是无法容忍的。为了解决这种冲突，一种可交换的全双工拓扑结构出现了：
传统的交换机根据一个路由表转发数据，这个路由表在交换机运行的时候创建，并且自动更新，它能够学习或者遗忘连接在其上的节点。当然，这种技术对于一个经常临时挂载卸载节点的网络来说是非常合适的。但是这个学习进程导致了可变的延迟在航空电子网络中必须要消除。因此，一个 AFDX 交换机根据一个静态的路由表来转发数据。事实上，一个通常的策略是静态地定义所有节点以及它们各自的网络地址。因此也不需要使用 ARP 从 IP 地址上解析 MAC 地址。
为了提高网络的可靠性，在物理层上设计了冗余。每个数据包都会通过两个网络控制器从独立的两个线缆独立的物理交换机发送到目标系统。
在目标系统上，两个独立的网络控制器接收到了这个数据帧，协议层的冗余管理算法将俩个相同数据包中的一个适当地转发到上层。
物理冗余可以在每个连接的基础上配置，从而允许使用较少的数据链路，对可用性的要求也较少，还能够利用第二条数据链路提供的额外带宽。
3.2、子系统、AFDX 端系统和交换机
一个 AFDX 网络由端系统（End Systems）和交换机（switches）。端系统是一个连接到 AFDX 网络的组件，能够处理所有 AFDX 相关的协议操作（这意味着端系统上能够处理协议）。通常，端系统是航空电子系统中的一部分，通过 AFDX 网络收发数据。
4、主机通信 API
在第一节中已经提到了，AFDX 技术是在 IMA 技术的环境中使用的。行业同样为 IMA 系统 API 指定了一个名为 ARINC-653 APEX 的标准。这个 API 将所谓的端口（Ports）定义为应用程序与自身上下文之外的实体交换数据的唯一方式。这些实体也许是本地硬件上的设备驱动，或者是连接远程计算机的数据通道。它的优势如下：
- 应用使用统一的 API 来进行数据交换；
- 通道配置独立于端口，因此通道配置的改变对使用这个端口的应用来说是透明的。
ARINC-653 定义了两种 Ports，Queuing Ports 和 Sampling Ports:
4.1、Queuing Ports
Queuing Ports 是以信息为导向的；一个已预设深度的队列（queue）接收信息直到所有空间被占用。进一步尝试将消息放入队列将导致应用等待，直到有空间释放出来，如果 Ports 运行在阻塞模式下。单个源队列只能连接到一个目标端口（一对一关系）。
4.2、Sampling Ports
从原理上来说，Sampling Ports 是深度为一条 message 的 Queuing Posts。因此，新的信息将覆盖未被读取的旧信息。该配置允许指定一个刷新率。消息的年龄将用来与刷新率相比较，根据读取服务调用的结果返回数据的有效性。它可以将一个源端口与多个目标端口连接（一对多关系）。Port API 提供一系列方法读写源端口和目标端口。在 Samplling Ports 上运行的服务调用不会阻塞。
4.3、Service Access Point（SAP）Ports
ARINC-653 定义了两种不同的 Port 类型，但是 AFDX 出现了第三种类型，即：SAP Port。大体上，这个端口类型是一个能够让 API 使用额外参数的 Queuing Ports 类型。对 SAP port 的要求是能够与基于 TCP/IP 的传统网络（兼容网络）进行通信。这种通信用于将文件传输到文件服务器，或者用新的软件更新航空电子系统。为了能够与兼容网络通信，发送端 End System 需要有能力指定目标地址：即 IP 地址和端口号。为了达到这个目的，当 End System 从兼容网络接收请求时，这些地址被设置成可用。
对 SAP port 的准确 API 没有在标准中指定；然而使用一个著名的伯克利 UNIX Socket API 的子集是可行的。
5、Virtual Link 概念
ARINC-429 最让人合意的特性是它在发送者和接收者之间使用了私有的连接。这个连接的物理带宽是永远可用的，也不会有同时发送导致冲突的情况。当内部连接航空系统与不同等级的临界情况时，这种程度的分离式强制性的。AFDX 技术通过采用虚拟连接（VL）的概念来实现这种分离。每个逻辑连接都用 VL 来代表，以此提供与传统 ARINC-429 连接相同的属性：一个具有有限延迟和保证带宽的单行私有线路。给定 VL 的识别是通过使用 48 位 MAC 地址中的 16 位作为 VL id来完成的。由于 IEEE 802.3 标准允许在以太网上进行多播包传输，因此可以使用标准机制将包路由到多个目标节点。然而，AFDX 的一个特性是 VL 可以有且只有一个终端系统向它发送数据。
对带宽的控制是通过约束每个 VL 的时间来实现的。将 VL 映射到全球交换机网络，实现了拓扑的划分。每个 VL 都有一个称之为 BAG（Bandwidth Allocation Gap）的时间分片以及一个最大帧大小。每个 VL 的 BAG 包是 End System 发送的两个连续 IP 帧之间的精确时间单位。一个 VL 可能使用不到所有的带宽，例如：两个连续的包之间的时间大于一个 BAG，但是它不能比 BAG 还小，End System 有责任对此进行限制。ARINC-664 规范允许 BAG 的值在 1~128ms 范围内取值为 2n（BAG=2n, n={0…7}）。
6、发送调度
终端系统的职责是根据每个虚拟链路分配的时间预算来调节所有的出站流量。因此，直到 BAG 消失之前，一个 VL 传输会被一直阻塞。下图说明了单个 VL 的流量规则的效果，当一个 VL 符合条件但是没有数据传输的时候，不会传输帧。
当来自多个 VLs 的出站包流被合并以进行传输时，有可能有一个以上的 VL 已准备好数据包，并符合传输条件
7、实现 AFDX
AFDX 技术已经成功在 A380 项目上部署。通常来说，有两种方式实现一个 AFDX End System。
7.1、ASIC 技术
专用集成电路（英语：Application Specific Integrated Circuit，缩写：ASIC）。在 A380 上所有端系统（End System）都是用 ASIC 技术构建，这意味着，AFDX 协议通过可编程逻辑设备使用硬件来实现。本质上来说这种方式具有更高的性能，同时也很好验证。但是另一方面，两大技术集成商——空客和波音——已经与 arinc664 标准产生了明显的偏差，需要一定的灵活性来适应这些差异。
7.2、固件
另一种实现方式是使用一个嵌入式 CPU 以及需要的硬件。例如：内存、两个以太网控制器、航电系统通信接口。在这种情况下，完整的 AFDX 协议栈作为固件运行在嵌入式 CPU 上。通常，有必要在单独的硬件上实现 AFDX 协议，以将主 CPU 从 AFDX 协议的时间和性能要求中解脱出来。主机 CPU 有实时的需求，因此网络流量的影响必须与它解耦。但是对于只有 LRU 设计（只有很少的 AFDX 性能需求）需求的情况下，在一个 CPU 上实现软件栈和应用软件也是可行的。
这种设计自由已经显示了 AFDX 协议的软件实现的主要优势：与硬件实现相比，设计的灵活性非常突出。前面已经提到，标准已经面临来自真实世界实现的偏差，进一步的性能需求和/或技术变化肯定会导致协议的变化 (或增强)。例如，希望使用千兆以太网就是一个很好的例子。对软件进行更改本来就比更改硬件设计容易。