客户的产品如何基于蓝牙认证现状选择相应的认证方案呢？

　　本文主要包含以下部分：
　　1. 认证流程：QDID & DID
　　2. 认证类型：End Product，Subsystem & Component
　　3. 认证方案：四个典型的场景中推荐的认证方案
　　BQB 全称 Bluetooth Qualification Body，如果您的产品具有蓝牙功能，必须通过 BQB 的认证，这样才能在产品、包装、广告以及整个营销过程中使用蓝牙文字标志及蓝牙徽标。
　　
　　认证流程
　　BQB 的发证机构为 SIG（Bluetooth Special Interest Group）蓝牙技术联盟，一个完整的认证流程可分为 QDID 和 DID 两个阶段。
　　QDID（Qualified Design ID）
　　一般 原始模块 需要首先申请 QDID 认证，完成认证之后会获得相应的证书，证书中会体现产品类型，型号以及 QDID 号。我们通常说的 BQB 蓝牙认证就是指 QDID。
　　对于 终端产品 来说，QDID 是可选的，如果需要提交新的测试计划（QDID），也可以 继承（Combine） 原始模块 已经完成的部分测试项，只需要再测试增加、修改的测试项。
　　
　　DID（Declaration ID）
　　在通过 BQB 认证获得 QDID 后，必须要申请 DID（Declaration ID） 来引用（Reference）原始模块 的 QDID。这样 BQB 的认证结果就可以在 SIG 官网查询：https://launchstudio.bluetooth.com/Listings/Search，
　　
　　一个 DID 可以包含一个或多个 QDID，一个 QDID 也可以被一个或多个 DID 引用。使用 DID 的好处是可以使终端厂商的认证过程简单化，并激励更多的产品加入蓝牙认证。
　　举例：对于蓝牙音箱成品来说，如果蓝牙模块已经通过 BQB 认证，那么蓝牙音箱这个产品可以不用重新申请认证，只要取得模块供应商的授权，就可以把产品以 DID 的形式在 BQB 网站声明。
　　认证类型
　　按照系统的复杂度，可以将认证产品分为 End Product，Subsystem 和 Component 三种。乐鑫产品的认证类型主要有 Subsystem 和 Component 两种。
　　Component （终端产品）
　　最小的认证单元，不能被 DID 直接引用。
　　可以被 Subsystem 和 End Product 继承。
　　如有需要，可以修改测试项重新做测试。
　　可分为 Tested 和 Non-Tested 两种。
　　Subsystem（子系统）
　　一个完整的子系统，可以被 DID 直接引用。
　　可以直接做测试，也可以继承已做过认证的 Component， 但不能被 End Product 继承。
　　如有需要，可以修改测试项重新做测试。
　　可以分 Controller Subsystem ，Host Subsystem，Profile Subsystem 等。
　　End Product（组件）
　　必须是一个完整的系统，可以被 DID 直接引用。
　　可以直接做测试，必须同时继承 Host Component 和 Controller Component。
　　如有需要，可以修改测试项重新做测试。
　　举例：一个蓝牙音箱去做 End Product 认证，可以同时继承已有的 Host Component 和 Controller Component，并重新测试 A2DP 的测试项，如 TCRL（Test Case Reference List）有变动，即使 Host Component 已经做过 A2DP 测试，A2DP 也需要重新测试。
　　按照认证产品是否跟硬件相关，可以分为与硬件相关的认证以及与硬件无关的认证。
　　与硬件相关的认证
　　这一类的认证与硬件相关，在终端产品继承或者引用原始模块时，需要确认硬件是否有改动：若无，只需要购买 DID 直接引用 QDID 即可；若有，则需要重新做测试认证。
　　以下列出 ESP32 与芯片和模组有关的蓝牙认证。
　　
　　与硬件无关的认证
　　这一类的认证与硬件无关，只要使用 ESP-IDF 里 Bluedroid Host 的蓝牙产品，这些认证同样适用，终端产品只需要购买 DID 并直接引用原始模块的 QDID 即可。
　　以下列出 ESP32 与 ESP-IDF Bluedroid 有关的蓝牙认证。
　　
　　认证方案
　　那么客户的产品如何基于乐鑫的蓝牙认证现状选择相应的认证方案呢？
　　基于以往的认证测试经验，对于使用 Controller 协议（除 RF 以外）和 Host 协议的客户产品，乐鑫的认证项目均能符合需求。只有 RF/RF-PHY 和 Profile 协议会出现已经通过的测试项不能符合客户需求，此时需要针对不同场景来选择不同的认证流程。
　　以下基于 RF和 Profile 是否符合客户需求的四个场景来做具体分析。
　　
　　场景1 - RF 和 Profile 均满足需求
　　客户使用乐鑫已经做完认证的模组，并且使用的 Profile 已在 Host Subystem 认证项中。即 Host Subsystem（包含了 A2DP，HFP 等常用 Profile）和 Controller Subsystem 满足客户需求。
　　方案1：直接引用
　　购买 DID，直接引用乐鑫 Host Subsystem + Controller Subsystem。
　　方案2：End Product 认证 + 引用
　　做 End Product 认证，继承乐鑫 Controller Component + Host Component，重新做部分 Profile 的测试。
　　购买 DID，引用客户 End Product 的 QDID。
　　场景2 - 只有 RF 不符合需求
　　通常是客户的产品使用自定义模组，其他 Controller、Host、Profile 协议均符合需求。
　　方案1：直接引用
　　做 Controller Subsystem 认证，继承乐鑫 Controller Component，重新做 RF/RF-PHY 测试。
　　购买 DID，引用客户 Controller Subsystem + 乐鑫 Host Subsystem。
　　方案2：End Product 认证 + 引用
　　直接做 End Product 认证，继承乐鑫 Controller Component，重新做 RF/RF-PHY 和部分 Profile 测试。
　　购买 DID，引用客户 End Product 的 QDID。
　　场景3 - 只有 Profile 不符合需求
　　客户产品使用已经做过认证的 ESP32 模组，但缺少一些 Profile 的认证。
　　方案1：Subsystem 认证 + 引用
　　做 Profile Subsystem 认证，测试需要的 Profile。
　　购买 DID，引用客户 Profile Subsystem + 乐鑫 Host Subsystem 和 Controller Subsystem。
　　方案2：End Product 认证 + 引用
　　做 End Product 认证，测试需要的 Profile。继承乐鑫 Host Component 和 Controller Component。
　　购买 DID，引用客户 End Product 的 QDID。
　　场景4 - RF 和 Profile 都不符合需求
　　客户产品使用自定义模组，并缺少一些 Profile 的认证。
　　方案1：Subsystem 认证 + 引用
　　做 Profile Subsystem 认证，测试需要的 Profile。
　　做 Controller Subsystem 认证，继承 Controller Component，测试 RF/RF-PHY。
　　购买 DID，引用客户 Profile Subsystem + Controller Subsystem + 乐鑫 Host Subsystem。
　　方案2：End Product 认证 + 引用
　　做 End Product 认证，继承乐鑫 Host Component + Controller Component，测试 RF/RF-PHY 和需要的 Profile。
　　购买 DID，引用客户 End Product 的 QDID。
　　注意事项
　　上述提到的，都是最快速、节省费用的方式，不排除有其他方案。
　　无论使用哪种认证方式，任何产品都必须包含一个完整的系统。比如一个音箱产品，不论直接引用还是先做 End Product 认证，都必须包含 Controller + Host + Profile，Dongle 和模组类型产品除外。
　　如果两个产品，只是外壳变化，蓝牙芯片、PCB、RF 等都没有变化，可以直接在对应的认证结果里的 Product List 里添加对应的产品。