4. Simplicity Studio与互操作测试工具链

互操作测试不是“把两个设备放在一起看能不能连上”这么简单。它需要一套能同时观察空口报文、控制被测设备行为、并记录判定结果的工具链。Silicon Labs 提供的 Simplicity Studio 是这套工具链的集成入口，Network Analyzer 负责抓取并解析 IEEE 802.15.4 / Zigbee 空口数据，Zigbee Test Tool（ZTT，基于 Zigbee Test Harness）则用于向被测设备发送标准化的测试命令、读取属性并执行互操作用例。本节围绕这三者的配置与协同使用展开，目标是让读者能够独立搭起一条可复现的互操作测试链路。

一、工具链的分工与数据流

在动手配置之前，先明确三者在测试中的角色。Simplicity Studio 是开发与调试的宿主环境，负责工程管理、固件烧录、串口终端和调试适配器（如 WSTK 板载 J-Link）的连接；Network Analyzer 是空口监听器，通过一个运行 RAIL/PTI 固件的监听节点（常见为另一块 EFR32 开发板）捕获信道上的帧，并借助 Simplicity Studio 中的 Zigbee 协议解码库把原始字节还原为 NWK/APS/ZCL 层字段；Zigbee Test Tool 运行在 PC 上，通过串口或 TCP 与作为“测试仪”的协调器节点通信，向被测设备（DUT）下发 ZCL 读写、绑定、报告配置等命令，并返回结果。

三者的数据流可以这样理解：ZTT 发出测试命令 → 测试仪节点经空口发给 DUT → DUT 回包 → 监听节点把同一空口上的双向帧交给 Network Analyzer 解码显示。因此，ZTT 决定“测什么”，Network Analyzer 决定“看到了什么”，Simplicity Studio 决定“设备怎么被烧录和连接”。

二、Simplicity Studio 的基础配置

安装 Simplicity Studio 后，第一件事是安装与目标器件匹配的 SDK。以 EFR32MG21 为例，在 Launcher 的“Update Software”中勾选 EmberZNet SDK（例如 7.4.x）与 Gecko SDK，并确保 Zigbee 协议栈组件已包含。随后通过 USB 连接 WSTK，Studio 会自动识别板卡并列出可用的示例工程。互操作测试通常不需要从零建工程，直接使用 Zigbee – SoC Coordinator 与 Zigbee – SoC End Device 两个示例即可：前者烧录到测试仪节点，后者烧录到 DUT。

烧录前需要确认几个关键参数，它们会直接影响后续抓包与测试能否对上：

• 信道：默认 11（0x0B），互操作测试建议固定为 15（0x0F），避开常见 Wi-Fi 干扰；
• PAN ID：示例中可设为 0xBEEF，测试仪与 DUT 必须一致；
• 发射功率：WSTK 默认约 0 dBm，近距离测试可降到 -10 dBm 以减少饱和；
• 串口波特率：ZTT 与测试仪通信常用 115200，需与固件中的 CLI 配置一致。

烧录完成后，打开 Studio 内置的 Console（Terminal），选择对应串口，输入 version 或 info 可看到协议栈版本与网络状态。这一步是确认“设备活着且固件正确”的最快方式。

三、Network Analyzer 的抓包配置

Network Analyzer 需要一块独立的监听节点。将 RAIL – Network Analyzer 或带 PTI 接口的固件烧录到第二块 EFR32 开发板，用 USB 连接 PC。在 Studio 中打开 Network Analyzer 视图，点击“Capture”旁的配置按钮，关键设置如下：

Channel:        15 (0x0F)
Radio Config:   IEEE 802.15.4 2.4 GHz
Capture Mode:   Network Analyzer (PTI)
Decode:         Zigbee (EmberZNet)
Filter:         PAN ID = 0xBEEF
Display:        Time | MAC | NWK | APS | ZCL

配置完成后点击开始捕获。此时如果 DUT 与测试仪正在通信，应能看到周期性的 Link Status、Data Request 以及 ZCL 帧。若看不到任何帧，优先检查三点：监听节点是否烧录了正确的 PTI 固件、信道是否与 DUT 一致、天线是否接好。Network Analyzer 的过滤功能很实用，例如只显示 APS 层且 Cluster ID 为 0x0006（On/Off）的帧，可以快速聚焦到被测功能。

四、Zigbee Test Tool 的配置与用例执行

ZTT 通常随 Zigbee Test Harness 一起提供，运行在 PC 上。启动后首先配置与测试仪节点的连接：选择串口（如 COM5）或 TCP，波特率 115200，然后点击 Connect。连接成功后，ZTT 会读取测试仪节点的 EUI64 与当前网络参数，界面上应显示 Coordinator 状态为“Formed”。

接下来配置测试参数。以验证 DUT 的 On/Off Cluster 互操作为例，在 ZTT 中依次设置：

• 目标地址：DUT 的短地址 0x1A2B，端点 1；
• Cluster：0x0006（On/Off）；
• 命令：0x00（Off）或 0x01（On）；
• 期望响应：ZCL Default Response，Status = 0x00（SUCCESS）。

点击发送后，ZTT 会显示命令是否被确认、响应时间以及返回的 Status。与此同时，Network Analyzer 中应出现对应的 ZCL 帧。把两者对照起来看，就能判断失败发生在哪一层：如果 ZTT 显示超时且抓包中根本没有 APS 帧，问题可能在入网或路由；如果抓包中有 APS 帧但 ZCL Status 非 0x00，则是 DUT 应用层未正确实现该命令。

五、一次完整的互操作验证示例

下面给出一个可复现的验证流程，用于确认 DUT 能正确响应 Read Attributes 命令。假设 DUT 已入网，短地址 0x1A2B，端点 1，Basic Cluster（0x0000）的 Model Identifier 属性 ID 为 0x0005。

1. 在 ZTT 中选择 ZCL Read Attributes，目标地址填 0x1A2B，端点 1，Cluster 0x0000，Attribute 0x0005；
2. 发送命令，观察 ZTT 返回的响应；
3. 在 Network Analyzer 中找到对应的 Read Attributes Response 帧，展开 ZCL 层，确认 Attribute Status 为 SUCCESS，且 Value 为可读字符串（如“DUT-01”）；
4. 若响应中的 Status 为 0x86（UNSUPPORTED_ATTRIBUTE），说明 DUT 未实现该属性，需检查固件中的属性表；
5. 记录用例编号、DUT 固件版本、信道、PAN ID、发送时间、响应时间与判定结果。

这个流程的价值在于：ZTT 给出“命令是否被接受”的结论，Network Analyzer 给出“空口上实际发生了什么”的证据，两者结合才能形成可追溯的互操作测试记录。只依赖 ZTT 的 PASS/FAIL 而不看抓包，遇到失败时往往无法定位原因；只抓包而不下发标准化命令，则无法保证测试用例的一致性。

六、配置检查清单

在开始正式测试前，建议按以下清单逐项确认，避免因配置不一致导致误判：