Zigbee 认证不是“把样机交给实验室，跑完测试就结束”。技术实现、正式测试、申请审核和认证后的变更管理属于不同责任主体。

先确认认证对象

常见对象包括：

  • Compliant Platform：无线芯片、处理器和 Zigbee 协议栈形成的平台基础；
  • Certified Product：面向最终用途的完整产品；
  • 认证转移、产品系列或相似产品路径：是否适用由当前政策决定。

大多数终端产品以合规平台为基础，但平台证书不会自动覆盖产品的 Endpoint、Device Type、Cluster 和应用行为。

全流程

1
2
3
4
5
6
7
8
9
10
11
12
确定产品与市场范围
  -> 确认 CSA 会员与认证路径
  -> 选择合规平台
  -> 冻结规范和测试输入
  -> 完成实现与 PICS / PIXIT
  -> 内部自测
  -> 选择授权测试机构
  -> 正式测试与问题关闭
  -> 提交认证申请与报告
  -> CSA 审核
  -> 证书、公开记录与标志授权
  -> 版本变更与再认证判断

开发阶段要准备什么

至少固定以下内容：

  • 硬件、软件和固件版本；
  • 合规平台及其证书范围；
  • Endpoint、Profile ID、Device ID；
  • Server / Client Cluster；
  • Mandatory、Optional 和 Conditional 能力；
  • commissioning、安全与网络类型；
  • 量产配置和认证配置差异；
  • 目标生态的附加要求。

生态认证和 Zigbee 认证是两套范围。通过 CSA Zigbee 认证，不自动代表通过某个商业生态的兼容性认证。

PICS 与 PIXIT

  • PICS 声明实现支持哪些协议能力；
  • PIXIT 提供测试所需的实现参数；
  • 它们驱动用例选择，也是实验室解释行为的依据。

填写原则是“与被测固件真实能力一致”。少报会导致声明不实，多报会扩大测试范围并暴露未完成能力。

授权测试机构做什么

授权测试机构根据冻结的测试计划和 PICS：

  • 审核样机与文档；
  • 配置正式测试环境；
  • 执行必选及已实现可选能力的用例；
  • 记录偏差和失败；
  • 在问题关闭后出具正式测试报告。

测试机构不替代产品团队做 Device Type 设计，也不能用口头经验覆盖规范和 PICS。

CSA 审核做什么

正式测试通过后，还需要通过 CSA 的认证工具提交申请材料。审核关注产品身份、声明、测试报告、合规平台和政策要求。批准后，产品才会获得对应证书、公开记录及标志使用资格。

“实验室测试通过”和“CSA 已正式认证”必须分开表述。

失败与重测

出现失败时，建议维护：

  1. 用例、前置条件和失败步骤；
  2. 规范条款与 PICS 项；
  3. DUT、测试端、抓包时间线；
  4. 根因属于实现、环境还是用例解释；
  5. 修复影响范围；
  6. 实验室确认的重测集合；
  7. 新固件标识和回归结果。

不要在未与实验室确认前自行判断“只改一行，无需重测”。

认证后的版本管理

认证绑定具体产品和版本信息。后续变更应评估：

  • 协议栈或合规平台升级；
  • Device Type、Cluster、属性和命令变化；
  • 安全策略或 commissioning 变化；
  • 硬件和射频变化；
  • 修复是否触及已测试行为；
  • 是否适用转移、系列、相似或再认证路径。

当前版本提醒

截至本文更新时，Zigbee 规范、PICS 和认证工具仍在演进。项目名称里写“Zigbee 3.0”不代表可以自行选择任意历史输入；新申请是否继续采用某个 3.0 组合，应在立项时由 CSA 或授权实验室书面确认。

官方入口：