标签: 协议测试

引言 当前车辆诊断主要使用UDS诊断协议，通过诊断功能可实现获取车辆ECU的状态信息及进行数据刷写。但随着汽车架构的日益复杂，数据爆炸及远程诊断等状况逐渐出现，传统的诊断方法已不足以应对这些复杂性和快速变化，因此，SOVD（Service-Oriented Vehicle Diagnostics）诊断协议于2019年在ASAM启动，通过标准化的诊断服务和接口，旨在提高诊断效率、灵活性和准确性，以满足车辆的远程诊断、近端诊断和车内诊断需求。 为什么需要SOVD： 高效的数据传输：汽车产生的数据量日益增加，涵盖从车辆状态到行车习惯的各种信息，需要更强大的协议来处理和分析数据。SOVD协议实现了高速数据传输，显著提升了诊断效率和响应速度。 远程需求：随着车联网技术的发展，对远程诊断和服务的需求逐渐增加。 灵活性：SOVD协议允许在运行时动态地定义和调用服务，而不是依赖于静态的API描述，满足不同车辆和场景的诊断和服务需求。 标准化：SOVD协议提供了一个标准化的诊断框架和统一的诊断接口，使不同OEM和供应商的系统可以互操作，减少了专有协议带来的兼容性问题。 跨平台兼容：支持不同的硬件和软件平台，确保各种设备和系统之间的无缝通信。 图1 汽车诊断发展历程 SOVD——面向服务的动态诊断 相较于传统诊断协议，SOVD采用了面向服务的动态诊断特性： 服务独立性：在SOVD协议中，诊断功能被分解成独立的服务模块。例如，发动机诊断服务、制动系统诊断服务和电池管理诊断服务都是独立的。这些服务各自运行，不相互依赖，确保系统的灵活性和稳定性 松耦合：服务之间通过标准化接口进行通信，而不是直接调用。这意味着一个服务的变化不会直接影响其他服务。这种松耦合设计使得系统更易于维护和扩展。 服务重用：某个诊断服务可以在不同的车辆和系统中重复使用。例如，标准化的发动机诊断服务可以应用于多种车型，而无需为每个车型单独开发。这种重用性提高了开发效率，降低了成本。 服务发现机制：诊断服务可以在需要时动态发现，而不是预先绑定到特定的服务实现。这意味着车辆系统可以在运行时根据当前需求发现和调用最合适的诊断服务。 按需服务调用：SOVD协议支持按需调用诊断服务，而不是在系统启动时加载所有可能的服务。这种按需调用确保了系统资源的高效利用和服务的灵活性。当车辆某个部件需要诊断时，系统会发出请求，调用相关的诊断服务。诊断完成后，服务可以释放资源，等待下次调用。 实时响应和数据处理：动态诊断要求系统能够实时响应诊断请求，并处理和传输诊断数据。这种实时性对于确保车辆安全和性能至关重要，通过高效的通信协议（如HTTP、MQTT）和优化的服务实现，确保诊断请求能够快速响应，并实时传输诊断结果。 自适应能力：SOVD协议的动态诊断特性使得系统可以根据实际情况调整诊断策略和服务。例如，在不同的驾驶条件下或车辆状态下，系统可以自适应地选择合适的诊断服务和策略。 SOVD协议架构 图2 SOVD协议架构图 SOVD协议可支持远程诊断、近端诊断及车辆内部诊断三种场景： 远程诊断：允许技术人员或服务系统在不需要直接接触车辆的情况下，通过移动宽带网络远程访问车辆数据和控制系统。 近端诊断：当技术人员在车辆附近时，可以通过有线或无线方式连接到车辆的SOVD服务器，进行诊断操作。 车辆内部诊断：车辆内部的诊断任务可以独立于外部服务器或近场测试器运行，例如，车辆健康监测、预测性维护等。 SOVD协议在车端主要由SOVD网关、SOVD2UDS适配器、SOVD库及诊断管理器（AUTOSAR AP）四部分组成： SOVD网关：为SOVD边缘节点，用于接收SOVD请求，使用mDNS进行设备的发现和连接，将其正确的分发到不同的终端。每个车辆中只有一个该组件。 SOVD2UDS适配器：可将基于SOVD协议的诊断请求和数据转换为符合UDS协议的格式，反之亦然。该组件原生支持DoIP，且可扩展自定义TP。每个车辆中只有一个该组件。 诊断管理器（AUTOSAR AP）：为车辆内部适用于AUTOSAR AP应用的本地SOVD服务器，可通过ara::diag (C++) 接口实现SOVD的功能。 该组件的数量取决于ECU/系统的数量。 SOVD库：适用于不具备完整AUTOSAR环境的应用，可以使用该组件实现SOVD功能。该组件的数量取决于ECU/系统的数量。 SOVD测试解决方案 北汇信息在对SOVD协议进行了深入理解及分析后，推出了系统级SOVD自动化测试解决方案及实车级SOVD自动化测试解决方案，下面就给大家介绍一下SOVD测试解决方案的整体构成。 通过对SOVD协议特性的解读，总结出针对SOVD协议，需覆盖以下测试场景: SOVD API测试：验证整车SOVD全部的API接口。 通过HTTP指令调用车端SOVD接口，并验证其协议一致性。 通过HTTP指令调用车端SOVD接口，观察SOVD2UDS适配器的表现是否符合预期 难点： 远程诊断服务器及车端SOVD接口的自动化调用。 可使用北汇定制化开发的Test Center软件完成自动化调用远程诊断服务器及车端SOVD接口 测试环境：系统级+实车级 测试输入物：API文档 SOVD2UDS测试 协议转换测试：验证SOVD协议的诊断请求和数据符合UDS协议格式转换的正确性。 通过HTTP指令调用车端SOVD接口，观察SOVD2UDS适配器的表现是否符合预期。 测试环境：系统级+实车级 测试输入物：API文档+诊断数据库 逆向场景测试：验证在ECU异常情况下，SOVD协议的诊断请求和数据符合UDS协议格式转换的正确性。 模拟UDS协议控制器的异常响应（否定响应或无响应），通过HTTP指令调用车端SOVD接口，观察SOVD2UDS适配器的表现是否符合预期。 难点： 逆向场景模拟 UDS控制器异常响应模拟：系统级SOVD测试台架环境下自动化实现总线/供电硬线故障注入、ECU总线信号无响应/否定响应等多种类型的逆向测试场景 测试环境：系统级 测试输入物：API文档+诊断数据库 鉴于以上SOVD自动化测试的内容，北汇信息在对SOVD协议做了深入分析后，推出了通用化的系统级及实车级SOVD自动化测试解决方案，在此基础上，再针对不同客户进行定制开发，从而实现系统级及实车级的SOVD自动化测试。下面就给大家介绍一下SOVD自动化测试系统的整体方案构成。 硬件层面，SOVD自动化测试方案针对不同客户的测试需求，可分为系统级测试系统及实车级测试系统两种形态。 系统级SOVD测试系统由测试机柜和测试台架两部分组成，其中测试台架上集成SOVD相关控制器及程控BOB设备，其中，通过北汇定制化开发的程控BOB设备，可实现控制器的故障注入，以完成逆向测试；测试机柜作为解决方案中的测试执行核心工具，通过总线仿真及采集接口卡进行总线报文的监控和仿真，工控机进行测试工程配置及执行，测试接口与测试台架进行连接。通过系统级SOVD测试系统可完成SOVD API测试、SOVD2UDS协议转换测试及SOVD2UDS逆向测试 实车级SOVD测试系统由测试机箱和户外电源两部分组成，其中户外电源是为SOVD测试机箱进行供电，主要针对燃油车和混动车进行配置，而针对具有自动补电功能的电车，可以考虑由车辆12V蓄电池为SOVD测试机箱进行供电。SOVD测试机箱作为解决方案中的测试执行核心工具，通过总线仿真及采集接口卡进行总线报文的监控和仿真，工控机进行测试工程配置及执行，测试接口与车辆进行连接。通过实车级SOVD测试系统可完成SOVD API测试&SOVD2UDS协议转换测试。 图3 SOVD测试系统硬件架构 在软件层面，SOVD测试解决方案由五大部分组成，分别是： 1. 逻辑定义模块（PAVELINK.Test Center）：通过北汇定制化开发的Test Center可实现图形化测试用例编辑、测试用例管理及设备管理、测试任务安排以及测试任务执行等工作，同时通过定制化模块也可实现自动化调用远程诊断服务器及车端SOVD接口。 2. 逻辑转发模块（PAVELINK.Test Agent）：通过北汇定制化开发的Test Agent可实现转发由上方Test Center下发的逻辑执行请求，包括CANoe工程调用，控制CANoe测试工程的自动运行，停止。 3. 数据库转换模块（PAVELINK.SOA-Converter）：通过北汇定制化开发的SOA-Converter可实现将OpenAPI及诊断数据库（ODX及DEXT等格式）的文件格式转换，用于测试用例生成工具生成测试用例 4. 测试用例自动生成工具： 1) 通过北汇定制化开发的测试用例自动生成工具，基于导入的数据库，可实现SOVD测试用例的自动生成 2) 通过VECTOR的CANoe.Diva，基于OpenAPI，可实现测试用例的自动生成，并进行特定用例的手动修改，从而对外部和内部的SOVD API接口进行测试 5. 测试执行软件（CANoe）：基于VECTOR的CANoe软件，可实现包含报文仿真、电源控制、信号仿真、以及BOB控制等 图4 SOVD测试系统软件架构 SOVD协议测试的测试流程如下： 测试前置条件 输入物：API及诊断数据库 输入物格式转换 通过PAVELINK.SOA-Converter自动化完成输入物的格式转换，并将其输入到测试用例自动化生成工具 测试用例生成 系统级SOVD测试用例：通过测试用例生成器解析输入物自动生成SOVD API测试用例、SOVD2UDS协议转换测试用例及SOVD2UDS逆向测试用例 实车级SOVD测试用例：通过测试用例生成器解析输入物自动生成SOVD API测试用例 测试执行及测试管理 测试用例输入到PAVELINK.Test Center，Test Center借助PAVELINK.Test Agent自动化调用CANoe、远程诊断服务器及车端SOVD接口进行测试执行，并根据测试结果生成测试报告 总结 在汽车行业的数字化转型浪潮中，SOVD（Service-Oriented Vehicle Diagnostics）协议的提出，不仅标志着车辆诊断技术的一次质的飞跃，更是对汽车安全性和智能化水平的一次深刻革新。 测试环节，对于确保SOVD协议的可行性和稳定性至关重要。北汇信息的SOVD测试解决方案通过覆盖API测试、协议转换测试以及逆向场景测试，确保每一个诊断服务都能在各种工况下准确无误地执行，从而保障车辆系统的可靠性和用户的安全性。 北汇信息的SOVD测试解决方案，采用先进的自动化工具和方法，结合系统级和实车级的测试环境，全面模拟各种可能的应用场景。这种全方位的测试策略，不仅提高了测试的效率和覆盖率，更是确保了技术的成熟度和应用的广泛性。 汽车行业的未来充满无限可能，SOVD协议及其测试解决方案将是我们探索这一未来世界的有力工具。让我们携手并进，以测试为桥梁，连接创新与实践，确保技术的每一步都坚实可靠。感谢您的阅读，期待与您在汽车技术革新的道路上相遇。

为什么要仿真特殊流量 在现网中，网络流量时常伴随着突发，突发流量可能会造成网络的拥塞，从而产生丢包、抖动和时延，导致网络服务质量整体下降。面对宏观上的突发，通常采用在网络设备入向限速或者流量整形功能来消除突发流影响。微观上的突发，比如毫秒级甚至纳秒级突发，则需要芯片级别处理。 针对以上痛点，我们需要在网络设备验证中引入宏观特殊流量，例如矩形波流量、三角波流量来验证设备的限速能力或流量整形能力，微突发流量来验证设备芯片转发能力。 Stream Manual Schedule定义特殊流量 Renix软件支持调度表方式构造复杂流量，如下图所示： 图中的参数，关系如下图所示： Entry：条目编号（只读） PortName：端口名称（只读） Name：调试条目名称（默认生成） Enable：使能该调底条目 StreamState：条目状态（只读） Stream Block Reference：关联流块（通过下拉框选择） Return to Entry：指定跳转条目（该条目调底结束后待调度条目），与Loop Count配合使用 Loop Count：指定Return to Entry动作的执行次数 Burst Count：指定关联流块的突发次数 Burst Size：指定每个突发的帧数量 Inter Frame Gap：指定突发内的帧间隔 Inter Burst Gap：指定突发间隔（Burst Count为1时只读） Inter Entry Gap：指定条目之间的调度间隔 Inter Frame Gap Unit/Inter Burst Gap Unit/Inter Entry Gap Unit：根据需要选择单位 在实际生产中，各项指标的构造，可参考以下换算： 突发流量大小：由Burst Size、Inter Frame Gap/Inter Frame Gap Unit和流量字节大小共同决定。 相同流量突发次数和间隔：由Burst Count、Inter Burst Gap/Inter Frame Gap Unit共同决定。 不同流量突发间隔：由Inter Entry Gap/Inter Entry Gap Unit决定。 流量杂复度组合：Return to Entry、Loop Count决定。 测试时可用以下公式换算： 常用值参考以下表格： 注：由于Brust Size只能取整，理论上存在误差。 如何使用仪表构造矩形波流量 信而泰Renix平台提供了Stream Manual Schedule,可灵活定义流量。假设业务如下所示： 采用100G接口 仪表交替产生1Mbps与2Mbps流量，波峰与波谷持续时间10秒 分别绑定2条流量，字节大小为256 创建流量 配置调度表 如下图所示，根据箭头指向逐个配置，根据表取得数据构造Entry，其中要求发流10秒则Brust Size*10。 查看结果 创建图表视图，选择PortStats下的“接收线速(bps)”选项，选择视图，如下图所示： 如何使用仪表构造三角波流量 信而泰Renix平台提供了Stream Manual Schedule,可灵活定义流量。假设业务如下所示： 采用100G接口 仪表产生三角波，波谷为1Mbps,波峰为8Mbps,Step为1秒 分别绑定8条流量，字节大小为256 创建流量 配置调度表 如下图所示，根据箭头指向逐个配置，根据表取得数据构造Entry。 查看结果 创建图表视图，选择PortStats下的“接收线速(bps)”选项，选择视图，如下图所示： 如何使用仪表构造纳秒级突发流量 信而泰Renix平台提供了Stream Manual Schedule,可灵活定义流量。假设业务如下所示： 采用100G接口 仪表产生突发流量，流量突发间隔为纳秒级，且循环发送 分别绑定2条流量，字节大小分别为64、128 创建流量 配置调度表 如下图所示，根据箭头指向逐个配置，纳秒级突发与包长、接口速率有关，如下表所示，包长与帧发送时长正相关。实现纳秒级突发，可根据需求选择包长。 查看结果 创建图表视图，选择PortStats下的“接收线速(bps)”选项，选择视图，如下图所示，图表视图最小采样间隔为1秒，故可通过抓包查看突发流量 DarYu-X系列测试仪 DarYu-X系列高性能网络测试仪是信而泰推出的面向高端路由器等高端数通设备的测试产品，具有高性能、高密度、高速率等特点，配置信而泰基于PCT架构的新一代测试软件RENIX和X2系列测试模块，可提供高精度的发包速率，为高端路由产品的研发保驾护航。

█ 到底 什么是BRAS ？ 宽带接入服务器（ Broadband Remote Access Server,简称BRAS）是面向 宽带网络 应用的新型接入网关，它位于 骨干网 的 边缘层 ，可以完成用户带宽的 IP /ATM网的数据接入。 宽带接入服务器（ BRAS）主要完成两方面功能： Ø 负 责终结用户的拨号连接（常见有 PPPoE、PPPoE双栈(ND)、PPPoE双栈(DHCPv6) 、 IPoE、IPoE 双栈 (ND)、IPoE 双栈 (DHCPv6)、 vll、vpls、 L3VPN、 L2tp、 IGMP+PPPoE、IGMP+IPoE、MLD+PPPoE、MLD+IPoE 等 连接）， 接入 汇聚用户的流量功能； Ø 与 认证系统 、 计费系统 和 客户管理系统 及服务策略控制系统相配合实现用户接入的认证、计费和 管理功能 。 BRAS是宽带接入网和骨干网之间的桥梁，BRAS与用户之间、用户与公网之间均通过传输网连接。 传输网是我们整个通信网络的底座，负责把各地的家庭用户、政企用户和数据中心连接起来。传输网 按功能分，又可以分为 骨干网和城域网 ， 如下图所示： 骨干网，又分为国家骨干网（一干）和省级骨干网（二干）。 城域网 ， 可理解为 单个城市范围内的通信网络（简称MAN，Metropolitan Area Network）。城域网也有进一步细分，分为三层：核心层、汇聚层、接入层 。 接入层，离我们用户端最近的一层 ， 同时也是 “光进铜退”的重点和难点。 接入层 目前最主流的光纤接入技术，就是PON ( Passive Optical Network )，也称无源光网络，主流PON技术架构如下： 传统 BRAS 一般部署在城域网的核心层， 南向面向用户接入，北向衔接骨干网流量， 实现网络的 IP接入一体化。现在比较流行的分层叫法，也会把 BRAS 所在的这层，叫做业务控制层。 BRAS 解决了宽带用户在业务上、流量上和管理上的汇聚，达到了用户终端只通过一条 网络连接 便可以 灵活、自主、方便地选择服务网络的目的 ， 适应了 宽带接入 网络应用 的 发展趋势 ，成为 宽带网络 在 接入层 和骨干 边缘层 之间重要的 网络单元 。 位置如下图所示： █ BRAS的发展演进 BRAS在ADSL时代就已经诞生了。当时宽带用户数量激增，BRAS有效地简化了网络架构，实现了集中化的管理功能，为宽带业务大爆发奠定了基础。 后来，它不仅支持了xDSL，还支持Cable Modem、以太网接入（LAN）、无线宽带数据接入（WLAN）、FTTx（也就是刚才我们说的光纤入楼、入户）等多种方式网络类型，支撑了宽带IP网络和ATM网络的数据接入，成为运营商和政企客户的最爱。 传统BRAS，作为网关，既要负责用户管理，也要负责数据流的转发，负担很重，性能很难提升上来。 于是，BRAS开始解耦，把将多台BRAS设备上的用户管理功能抽取出来并且集中，形成控制面（Control Plane，简称CP）。BRAS设备上，保留路由器的控制面以及BRAS的转发面，形成转发面（User Plane，简称UP）。 和移动核心网一样，除了把控制面集中起来之外，还引入了虚拟化（云化），形成了vBRAS。好处和云核心网是一样的，可以灵活进行弹性扩容、缩容，简化运维，统一标准接口，提升设备性能。 采用vBRAS之外，转发面也变得灵活。 对于大流量业务，可采用高性能硬件，分布式部署，满足转发性能需求。对于大session小流量业务，可采用x86云化设备，集中式部署，节约成本。 vBRAS的出现，体现了城域网云化的趋势。它的底层演进逻辑，和4G/5G移动通信网是一样的。 值得一提的是，除了形态变化之外，BRAS的定位也有些变化。 随着设备性能的提升，前面我们看到的在一起的BRAS和SR（业务路由器），设备功能逐渐融合为MSE（Multi-Service Edge，多业务边缘路由器）或BNG（Broadband Network Gateway，宽带网络网关）。这也是某种形式的合体。 █ 用户宽带接入 那么问题就来了，当 用户想要上网， 是什么样的流程呢？ 首先要确保PON的光通路 正常， 然后光猫（也可以是无线路由器）和BRAS之间，建立一个 PPP会话 。PPP，Point to Point Protocol（点对点协议），是一种数据链路层协议。建立PPP会话后，用户就可以访问互联网（接入骨干网）。PPP会话的建立过程如下图所示 : BRAS通过与认证系统和计费系统的配合，完成认证和计费功能。 值得一提的是，为了完成认证，还有一个重要的网元，那就是RADIUS服务器（Remote Authentication Dial In User Service，远程用户拨号认证系统）。 上述流程图 ，BRAS收到终端侧过来的用户名密码， 通常情况下由BRAS转到 RADIUS认证 授权 。 除了认证、鉴权和计费之外，BRAS还可以用于QoS、安全管理、组播和VPN等。 █ 如何使用仪表模拟用户接入（PPPoE为例） renix配置思路： Port1模拟3个PPPoE Client进行PPPoE拨号上网（可以模拟更多Client）； Port2模拟Internet端口； Port1开启PPPoE Client协议仿真，3个Client都获取到IP地址之后， Port1和Port2相互打流，预期流量可以打通。 测试拓扑如下： 测试步骤： 预约测试机框、占用端口 PPPoE Client配置 使用PPPoE向导配置、选择要配置PPPoE的端口 选择封装、配置接口，“每接口地址数”设置为3，表示3个PPPoE Client 配置PPPoE、PPPoE角色选择Client 认证方式选择 CHAP MD5认证，用户名renix_1，密码XINERTEL_1 向导配置完成后, 还可以修改 修改用户名分别为 renix _1、 renix _2、 renix _3 修改密码分别为XINERTEL_1、 XINERTEL_2 、 XINERTEL_3 订阅 PPPoE Client Session Statistic 统计 启动PPPoE协议 查看PPPoE Client 统计 3个PPPoE Client都已经成功建立连接 3个PPPoE Client获取到的IP地址分别为：102.1.1.2 29 、102.1.1. 118 、 102.1.1. 191 在Port2下添加IPv4接口，并修改对应参数 修改IPv4地址为103.1.1.2（与DUT直连端口在同一网段即可） ， IPv4网关地址为103.1.1.1 选中创建的interface，右键选择“发送ARP/ND”，即可学习到DUT的MAC地址 （ 68:E2:09:34:16:9C ） 添加绑定流 选中“流模板”，右键选择“新建绑定流”会弹出新建绑定流的对话框 选择要建立绑定流的2个端口，点击“下一步” 添加绑定流 常规界面默认即可，点击“下一步” （也可以根据需要修改参数） 添加绑定流 ， 帧界面不用修改，点击“完成 发送流量/查看统计 切换到Stream Block Statistic界面查看发送和接收速率及其它统计项，下图表明发送和接收报文速率相同，可以适当加大带宽继续测试 停止PPPoE协议 ， 查看流量收发情况 结果显示，流量收发正常，且流量无丢包。

前言 在网络部署之后和业务开展之前，运营商迫切希望了解当前网络的性能状态，以便为商业规划和业务推广提供必要的基础数据支持。因此，高可靠性和高精确度的性能测试方法对于运营商评判网络性能的优劣，显得尤为重要，而RFC 2544等传统测试标准已不足于鉴定当今的服务等级协议（SLA）。SLA是服务提供商（如ISP）及其最终用户之间的协议，它规定以太网服务的开通或验证必须进行测量，且必须达到SLA的规范要求。目前，对以太网服务进行测试和故障诊断的最佳选择无疑是ITU-T Y.1564标准。 Y.1564和RFC2544对比 RFC2544 对比Y .1564 不同之处，在于以下几个方面： RFC2544主要是用来测试网络设备（交换机、路由器等）的极限性能。 Y.1564将网络视作一个整体,测量网络端到端的服务质量QoS，同时可以测试网络是否满足服务层级协议SAC 、SLA的要求，测量更有针对性。 Y.1564 主要是用来测试运营商带宽，这里不再是网络设备测试。为接近链路的极限带宽，Y.1564考虑到了多业务数据流带宽分配的因素，在多服务相互干扰下对每个业务数据流独立统计其性能参数矩阵，得到接近真实网络环境下的网络运行状况和服务质量。 RFC544的测试比较耗时间，而Y.1564为一次性测试。测试带宽为递增带宽， 一次性可测量多数据流在网络的配置和性能各方的情况，具有巨大的优势 Y.1564测试方法在实际情况下非常有效，可大幅缩短测试时间，准确地提供所有SLA指标的可视性，从而消除重复工作。 Y .1564 测试解决方案 信而泰 BigTao -V 系列以及DarYu -X 系列支持Y .1564 测试套件，Y .1564 测试分为两个阶段：配置测试和性能测试。 测试原理： 测试仪通过TX端口按照一定的速率发送流量到DUT，然后通过RX端口接收DUT转发的流量。并且最终获取相应的统计值，进行判断是否测试通过。 配置测试： 用于验证每一个Service配置的SLA参数是否能够正确执行，比如用户Service能否在保证SAC的情况下稳定运行在CIR速率上。 SAC主要包括：FLR（丢帧率），FTD（延迟），FDV（抖动）和AVAILABILITY（可获得性） 配置测试项包括：CIR测试，EIR测试，Traffic Policing测试，CBS测试和EBS测试。 CIR测试 C IR 测试指的是运营商和用户签约的承诺速率，该速率发送的流量运营商网络保证可以送达。测试目的就是验证用户发送满足CIR速率的流量，运营商网络以CIR速率转发，并且满足SAC指标。 E IR 测试 EIR指的是运营商和用户签约的超出CIR的速率，该速率发送的流量运营商网络不保证可以送达。当出现网络拥塞时，会丢弃EIR流量。 EIR测试的目的就是验证用户发送满足CIR +EIR 速率的流量，运营商网络以不小于CIR，不大于CIR +EIR 速率转发。 Traffic Policing 测试 Traffic Policing 测试的目的就是验证用户发送满足CIR +125%*EIR 速率的流量，运营商网络以不小于CIR，不大于CIR +EIR 速率转发。超出CIR +EIR 部分统统丢弃。 CBS 测试 用户发送的流量，并不总是保持恒定的速率，绝大多数是以突发形式出现。比如突然发送个图片，一大段话。这类数据的数据量并不大，但是会瞬间超出CIR速率，这样会导致用户数据传递不可靠。因此CBS就是指的是运营商承诺的一块数据大小，当用户突发传送的数据速率超出CIR但是大小小于CBS，可以保证可靠传递。 CBS测试的目的就是验证用户发送小于CBS突发数据时，运营商网络能否保证可靠传递。 EBS 测试 当用户突发流量大于CBS，小于EBS时，运营商网络可以传递，但是不保证可以送达。 EBS测试的目的就是验证用户发送大于CBS小于EBS突发数据时，运营商网络能否传递。 配置测试项结果如图 性能测试 用于验证多个Service并行运行的情况下，系统性能的表现。性能测试项会并行运行当前所有配置的Service，每个Service都在CIR速率运行，然后统计最终的SAC 所有配置的Service按照CIR速率全速发送流量，维持一段相当长的时间（1 5 分钟- 24 小时），然后获取统计值，观察是否满足SAC。 性能测试项结果截图 结语 Y.1564标准相较于传统的RFC 2544等测试方法，更具实用性和准确性，能够更好地评估以太网络的性能，特别是在评估以太网服务的能力、容量和性能方面表现突出。同时，通过Y.1564测试，运营商可以对网络质量进行快速、精确地检测，帮助他们在网络部署之后和业务开展之前及时了解网络性能状态，为商业规划和业务推广提供必要的基础数据支持。