*openUBMC 支持业务侧下电和重启生效的固件在注册固件清单时携带相关信息详细设计说明书*

<table>
    <tr>
        <td>所属SIG组:</td>
        <td>hardware</td>
    </tr>
    <tr>
        <td>落入版本:</td>
        <td>26.0</td>
    </tr>
    <tr>
        <td>设计人员:</td>
        <td>lisongwei</td>
    </tr>
    <tr>
        <td>日期:</td>
        <td>2026/01/13</td>
    </tr>
</table>

**Copyright © 2025 openUBMC Community**

您对&quot;本文档&quot;的复制，使用，修改及分发受木兰宽松许可证, 第2版协议(以下简称&quot;MulanPSL2&quot;)的约束。
为了方便用户理解，您可以通过访问<https://license.coscl.org.cn/MulanPSL2>了解MulanPSL2的概要 (但不是替代)。
MulanPSL2的完整协议内容您可以访问如下网址获取：<https://license.coscl.org.cn/MulanPSL2>。

**改版记录**

<table>
    <tr>
        <th>日期</th>
        <th>修订版本</th>
        <th>修订描述</th>
        <th>作者</th>
        <th>审核</th>
    </tr>
    <tr>
        <td>2026/01/13</td>
        <td>1.0</td>
        <td>支持业务侧下电和重启生效的固件在注册固件清单时携带相关信息</td>
        <td>lisongwei</td>
        <td>/</td>
    </tr>
</table>

**List of abbreviations**  **缩略语清单** ：

<table>
    <tr>
        <th>Abbreviations 缩略语</th>
        <th>Full spelling 英文全名</th>
        <th>Chinese explanation 中文解释</th>
    </tr>
    <tr>
        <td>CPLD</td>
        <td>Complex Programmable Logic Device</td>
        <td>复杂可编程逻辑器件</td>
    </tr>
    <tr>
        <td>MCU</td>
        <td>Microcontroller Unit</td>
        <td>微控制器</td>
    </tr>
    <tr>
        <td>VRD</td>
        <td>Voltage Regulator Device</td>
        <td>电压调节器器件</td>
    </tr>
    <tr>
        <td>SR</td>
        <td>Self Record</td>
        <td>自描述文件</td>
    </tr>
    <tr>
        <td>DPU</td>
        <td>Data Processing Unit</td>
        <td>数据处理单元</td>
    </tr>
</table>

[TOC]

# 1.功能分析
## 1.1 功能背景
<!-- 描述该需求的来源或背景，比如：支撑XXX功能、XXX优化等；以及该需求对用户（含组件）带来什么具体价值，如果没有该需求，对用户（含组件）带来什么损失； -->
为支持redfish固件升级暂存机制，需要框架支持通过redfish接口查询环境上哪些固件支持暂存，以及这些固件会应用在环境上的哪些器件。因此各组件向框架注册固件清单时，注册的信息中需要新增这些信息，从而允许框架进行获取并向外部呈现。

## 1.2 功能描述
<!-- 描述该需求交付的整体功能，主要实现XXX功能，解决XXX问题，明确方案如何实现 -->
本功能主要实现在组件初始化向框架注册固件清单时，注册信息中新增若干信息。包括固件是否支持暂存，以及这些固件对应的器件信息。

## 1.3 功能场景
<!-- 描述该需求的业务使用场景，内容包括：
1) 场景出发条件及对象：什么角色/工具/接口等在什么具体情况下使用该特性，使用对象技能如何？
2) 使用时间及频度
3) 描述该特性主要有哪些场景、子场景及关键任务操作 -->

### 1.3.1 场景触发条件及对象
使用角色：不涉及。使用工具：不涉及。使用技能：不涉及。

### 1.3.2 使用时间及频度
每次BMC启动运行后，本组件在初始化流程中向框架注册固件清单时自动执行。

### 1.3.3 主要场景及子场景
在本组件初始化流程中，向框架注册固件清单的场景中执行该功能。

## 1.4 功能列表
<!-- 描述该需求交付的功能列表，内容包括：列出功能详细描述，标题、描述。 -->
| 功能编号 | 功能标题 | 功能描述 |
| ------- | ------- | -------- |
| 1 | 注册固件是否支持暂存信息 | 在注册固件清单时，判断该种固件是否支持暂存，并进行注册 |
| 2 | 注册固件应用的设备清单信息 | 在注册固件清单时，判断该种固件能使用在当前环境的哪些器件上，并进行注册 |
| 3 | 注册固件匹配信息 | 在注册固件清单时，判断该种固件对应器件的匹配信息，并进行注册 |
| 4 | 注册固件类型信息 | 在注册固件清单时，判断该种固件的类型名称，并进行注册 |

# 2.功能设计
## 2.1 总体方案分析
<!-- 描述该方案的总体设计（注：相关输出方案可同步刷新到各组件仓） -->
本方案在组件初始化注册固件清单对象时新增注册属性，在注册的固件清单时，首先根据当前待注册的固件类型，判断该固件是否支持暂存。同时根据当前固件对应器件的对象信息，获取对应的设备清单信息和固件匹配信息，并将这些信息新增到需要注册的属性中，从而提供给基础服务使用。基础服务能够从固件清单对象中获取这些额外的信息，从而进一步开发其他依赖这些信息的功能。

### 2.1.1 方案详细设计
#### 2.1.1.1 方案概述
<!-- 描述该方案的整体实现，内容包括：涉及的关键点，实现策略等 -->
本方案在组件初始化的流程中，每种固件注册固件对象时新增以下属性：

1. StageSupported：表示该固件是否支持暂存功能。对于生效条件为业务侧下电或重启的固件，需要支持暂存，因此这些固件需要配置为true。其他生效条件的固件不支持暂存，配置为false。
2. RelatedItem：表示该固件应用的设备清单信息，指明当前环境上有哪些器件使用该固件对象进行升级。对于本组件而言，本组件在初始化时，会为环境上的每一个可升级的器件注册各自独立的固件清单，因此每个固件清单对象和每个器件是一一对应的，RelatedItem属性只需要配置一个器件即可。本组件可以在注册固件清单前获取该固件所在的单板名称，查询得到单板的NodeId，组装为基础服务需要的名称格式写入该字段。
3. ComponentID/SubComponentID/TargetUIDs：表示该固件的匹配信息，以便基础服务使用该属性与固件包中进行匹配。如上一条分析，本组件注册的固件清单与器件一一对应，因此对于这几个字段，同样各只需要注册一个值即可。这几个字段的取值来自于sr文件配置，因此可以读取固件在sr文件中的配置信息，将对应字段赋值给这几个属性注册。
4. FirmwareType：表示该固件的类型。本组件各种固件注册的代码是各自独立的，因此只需在各种固件的注册流程中写明注册的是哪种固件即可。

注意：只有当StageSupported取值为true的属性需要注册其余字段。若某个固件的StageSupported取值为false，则该种固件的RelatedItem/ComponentID/SubComponentID/TargetUIDs属性可以不注册，由基础服务生成默认值进行后续处理。

#### 2.1.1.2 运行视图
<!-- 运行视图面向系统运行，描述系统启动过程、运行期交互的视图，主要解决系统运行期交互，描述各可执行交付件在运行期的交互关系 -->
```mermaid
sequenceDiagram
    participant general_hardware as general_hardware组件
    participant hwdiscovery as 硬件自发现
    participant firmware_mgmt as 基础服务

    Note over general_hardware: 组件初始化
    hwdiscovery->>general_hardware: 硬件自发现下发firmware对象
    Note over general_hardware: 准备向基础服务注册FirmwareInventory对象，执行已有的属性赋值动作
    Note over general_hardware: 根据固件生效条件，判断固件是否支持暂存。判断规则如下：<br>CPLD：读取该固件在sr文件中配置ValidConditon属性，获取固件的生效条件，如果生效条件为ResetAC则支持暂存，否则不支持<br>MCU：通过固件接口读取固件的active_mode值，获取固件的生效条件，如果生效条件为ResetAC则支持暂存，否则不支持写入<br>其他固件：其他固件注册的生效条件与固件类型绑定，根据固件种类直接判断是否支持暂存
    Note over general_hardware: 将是否支持暂存写入StageSupported属性
    Note over general_hardware: 获取固件的所在单板的NodeId，构造该固件对应的设备清单信息，写入RelatedItem属性
    Note over general_hardware: 获取固件的ComponentID/SubComponentID/TargetUIDs属性，写入对应属性
    Note over general_hardware: 根据当前处理的固件类型，获取FirmwareType属性
    Note over general_hardware: 生成待注册参数组（以CPLD为例）：<br>StageSupported: 'true'<br>RelatedItem: '/redfish/v1/Chassis/1/Boards/EXU1ExpBoard1'<br>ComponentID: '255'<br>SubComponentID: '4294967295'<br>TargetUIDs: 'xxxxx'<br>FirmwareType: 'CPLD'
    general_hardware->>firmware_mgmt: 注册FirmwareInventory对象
    firmware_mgmt-->>general_hardware: 返回注册结果
```

### 2.1.2 内部依赖分析
<!-- 是否涉及与其他组件接口依赖，如果涉及需要确认当前是否已完成，是否匹配当前需求开发诉求 -->
基础服务依赖本组件完成当前需求开发后，使用新增的属性进行后续开发工作。本组件本身的开发工作不依赖其他组件。

### 2.1.3 外部依赖分析
<!-- 是否涉及与平台SDK的依赖关系 -->
不涉及

### 2.1.4 北向接口分析
<!-- 需要分析当前功能是否有以下接口影响，如果有影响，则需要具体的补充影响点。其中注意点如下：
（1）如果有新增IPMI接口，请排查代码中IPMI命令注册的过滤字段，是否完全和IPMI命令的定义一致？
（2）新增一个接口时，需要咨询SIG组是否还有其他的接口受影响 
（3）新增接口需要将对应接口属性名称和属性值列出，属性值若有单位、异常值处理、范围限制或格式规范也需要列出，对于标准接口需要列出标准接口文档中对应的属性名称和属性值相关规定-->
| 特性 | SNMP | CLI | WEB | KVM_VMM | IPMI(RMCP/RMCP+) | HMM | Redfish |
| ---- | ---- | ---- | --- | ------ | ---------------- | --- | ------- |
| 通用硬件子系统支持业务侧下电和重启生效的固件在注册固件清单时携带相关信息 | NA | NA | NA | NA | NA | NA | NA |

### 2.1.5 兼容性分析
<!-- 当前的功能对现有在网的功能是否有影响，具体的影响点进行分析之后输出影响分析表格 -->
不涉及

### 2.1.6 定制化接口分析
<!-- 如果支持定制化设置，则需要给出定制化时的默认值（空定制化项条件下的设置值），如果涉及到定制化接口变更或新增，注意定制化接口文档需配套修改。注意定制化默认值变更对白牌包的影响 -->
不涉及

### 2.1.7 导入导出分析
<!-- 如果支持导入导出的配置，则需要分析导入导出的schema。 -->
不涉及

### 2.1.8 传感器分析
<!-- 如果需要新增传感器，则需要提前登记和评审新增的传感器要素。新增传感器评审需要上SIG-Interface进行评审 -->
不涉及

### 2.1.9 精准告警事件分析
<!-- 如果需要新增事件，则需要提前登记和评审新增的时间要素 -->
不涉及

### 2.1.10 系统锁定分析
<!-- 对外的接口或者命令是否支持系统锁定 -->
不涉及

### 2.1.11 用例场景分析
<!-- 以表格的形式输出该需求涉及的用例场景 -->

| 用例编号 | 用例名称 | 前置条件 | 操作步骤 | 预期结果 |
| ---- | ---- | ---- | ---- | ---- |
| 1 | 注册FirmwareInventory对象，sr文件未配置ValidCondition | 1. BMC正常运行<br>2. sr文件中的固件对象正确配置<br>3. 固件对象的生效条件未配置（非RM310机型） | 1. 登录BMC后台，执行busctl命令查询firmware_mgmt组件下的FirmwareInventory对象属性，预期有结果a | a. 对于环境上的每个固件（CPLD、MCU、VRD、SR、DPU、Retimer），均查询到firmware_mgmt组件下有对应的FirmwareInventory对象，其中StageSupported属性满足要求：CPLD和VRD为true，其余固件为false
| 2 | 注册FirmwareInventory对象，sr文件配置ValidCondition为复位BMC | 1. BMC正常运行<br>2. sr文件中的固件对象正确配置<br>3. 固件对象的生效条件配置为复位BMC（RM310机型） | 1. 登录BMC后台，执行busctl命令查询firmware_mgmt组件下的FirmwareInventory对象属性，预期有结果a | a. 对于配置为复位BMC生效的固件，在firmware_mgmt组件下查询到有对应的FirmwareInventory对象，其StageSupported属性值为false，RelatedItem属性与该固件所在单板名称一致，TargetUIDs属性与sr文件中配置一致。
| 3 | 注册FirmwareInventory对象，sr文件未配置固件所在单板NodeId属性 | 1. BMC正常运行<br>2. sr文件中的固件未配置NodeId属性 | 1. 登录BMC后台，执行busctl命令查询firmware_mgmt组件下的FirmwareInventory对象属性，预期有结果a | a. 在firmware_mgmt组件下查询到有对应的FirmwareInventory对象，RelatedItem属性为异常。
| 4 | 注册FirmwareInventory对象，sr文件未配置UId属性 | 1. BMC正常运行<br>2. sr文件中的固件未配置UId属性 | 1. 登录BMC后台，执行busctl命令查询firmware_mgmt组件下的FirmwareInventory对象属性，预期有结果a | a. 在firmware_mgmt组件下查询到有对应的FirmwareInventory对象，UId属性为空。

### 2.1.12 装备能力差异分析
<!-- 当前功能是否在装备版本和Release版本中存在能力差异，若有差异需要进行说明 -->
不涉及

### 2.1.13 持久化分析
<!-- 当前的功能是否涉及持久化，尤其是持久化类型变更或某个属性新增了取值，是否兼容老版本 -->
不涉及

## 2.2 非功能质量属性设计
### 2.2.1 扩展性分析
<!-- 考虑后续新增类似功能可以很好地扩展 -->
本方案开发的功能具有良好扩展性，本方案新增注册属性均使用已有属性转换得到，同时注册对象的代码基于现有代码增量开发，未对当前代码框架产生影响。后续功能开发可继续基于当前框架开发。

### 2.2.2 重用性分析
<!-- 是否为通用处理方式、接口，如果是得考虑重用性 -->
本方案开发的代码为组件内部处理逻辑，不涉及重用性。

### 2.2.3 可测试性分析
<!-- 此需求如何验证，是否可直接验证，or通过XXX功能覆盖验证，or需要单独怎加测试接口验证 -->
本方案开发的代码可以通过后台查询资源树上FirmwareInventory对象的属性进行验证。

### 2.2.4 资料分析
<!-- 是否涉及资料修改 -->
不涉及

### 2.2.5 资源使用分析
<!-- 新增线程、内存分配、模型属性名长度是否合理，CPU占用率是否会激增，Flash中新增文件是否合理（频繁读写Flash会大幅缩短emmc寿命）；是否涉及消息队列，如果涉及请检查是否存在某些场景下消息队列会满导致消息丢失，例如大量消息发送到队列且处理消息需要耗费较长时间的场景。 -->
不涉及

### 2.2.6 可靠性分析
| 编号 | 场景 | 问题描述 | 可靠性影响 | 问题级别 | 建议解决方案/需求 | 讨论结果 | 跟踪人 | 备注 |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| 1 | 组件初始化场景 | 固件对象下发时，未配置ValidCondition属性 | 影响对于该固件StageSupported取值的判断 | 一般 | 按照各组件默认注册的生效条件判断该固件StageSupported的取值，注册生效条件为复位BMC的固件取值为false，其余固件取值为true。
| 2 | 组件初始化场景 | 固件对象下发时，固件所在单板未配置NodeId属性 | 影响对于该固件RelatedItem取值的判断 | 一般 | 在日志中进行记录，基于现有逻辑处理向基础服务注册RelatedItem属性。后续由日志指导定位sr文件配置异常问题。
| 2 | 组件初始化场景 | 固件对象下发时，未配置UId属性 | 影响对于该固件UId取值的判断 | 一般 | 在日志中进行记录，基于现有逻辑处理向基础服务注册UId属性。后续由日志指导定位sr文件配置异常问题。
### 2.2.7 安全性分析
| 安全合规项 | 是否涉及 | 现有的防护措施 |
| --- | --- | --- |
| 访问控制（通道、文件权限、用户权限、查询权限、配置权限、接口权限） | 不涉及 |  |
| 敏感数据 | 不涉及 |  |
| 日志（操作日志、维护日志、安全日志、运行日志） | 不涉及 |  |
| 文档 | 不涉及 |  |
| 加密及算法 | 不涉及 |  |
| 新增关键资源（密钥、证书、关键配置）备份、恢复 | 不涉及 |  |
| 新增对外接口入参校验 | 不涉及 |  |
| 新增开源及三方软件引入 | 不涉及 |  |
# 3.功能实现
<!-- 通过表格、流程图、简明文字描述提供，力求容易看懂、容易实现，详细描述细节。 -->
## 3.1 注册固件是否支持暂存信息
### 3.1.1 功能实现设计
本功能主要任务为组件初始化时，根据下发的固件信息，判断固件的生效条件，得出该固件的StageSupported属性并注册给基础服务。
### 3.1.2 功能详细设计
对于业务侧下电或重启生效的固件，StageSupported需要配置为true，其余固件需要配置为false。当前general_hardware下管理的各种固件以及生效条件对应情况如下：
| 固件类型 | 生效条件 | 生效条件来源 | StageSupported属性值 |
| ---- | ---- | ---- | ---- |
| VRD | PowerOff | 默认 | true |
| DPU | 立即生效 | 默认 | false |
| MCU | 立即生效/ResetAC | 根据硬件接口协议查询获得 | 根据生效条件判断 |
| Retimer | 立即生效 | 默认 | false |
| SR | ResetBMC | 默认 | false |
| CPLD | ResetAC/ResetBMC | 根据sr文件配置获取 | 根据生效条件判断 |
| FPGA | 立即生效 | 默认 | false |

因此各种固件的StageSupported属性按照如下策略注册：
- 对于VRD、DPU、Retimer、SR、FPGA的固件清单对象，只需要在注册流程中固定指定StageSupported属性为true或false即可（按上表决定取值）。
- 对于MCU，需要在注册前调用该固件的`query_active_mode`接口，查询该固件的生效条件。如果生效条件为ResetAC，则StageSupported属性注册为true，否则注册为false。
- 对于CPLD，需要在注册前查询该固件对应sr文件中的`ValidCondition`属性。如果该属性值为3（代表复位BMC生效），则StageSupported属性注册为false，否则注册为true。
### 3.1.3 开发者测试
<!--
增加模块接口：以活动图/流程图等形式明确模块内处理流程，针对模块处理流程中的分支进行覆盖
修改模块接口处理流程：覆盖修改影响流程分支
-->
对于各种固件的对象注册接口，添加打印信息，打桩验证注册固件对象时新增的注册资源符合预期。这些测试点同时也能覆盖到后文的功能点，因此之后章节的开发者测试部分不再重复列出。
#### 3.1.3.1 单元测试
<!-- UT，主要是功能单元测试，测试对象是功能单元接口。UT测试设计要从黑盒（功能）角度设计，从输入(I)、处理（B）、预期输出（O）的角度进行用例分析设计，测试覆盖率仅作为反馈，用于分析哪些功能场景没有覆盖到，从而指导测试设计优化并补充测试用例 -->
不涉及
#### 3.1.3.2 集成测试
<!-- IT，主要是组件/模块内的集成测试，测试对象是模块/组件接口。IT测试设计将模块/组件当作黑盒测试，IT测试用例中禁止对组件/模块内部代码打桩，如果确实有少量场景难以构造，可以考虑在测试框架中统一打桩并提供接口供测试用例调用构造场景。
说明：API测试属于IT，其测试对象是微服务接口。
PCST，是指PC上的服务集成测试，测试对象是功能需求。PCST测试设计，要覆盖正常功能、异常功能和交叉功能，采用灰盒 -->
不涉及
## 3.2 注册固件应用的设备清单信息
### 3.2.1 功能实现设计
本功能主要任务为组件初始化时，根据下发的固件信息，判断固件对应的器件位置，并生成RelatedItem属性注册给基础服务。
### 3.2.2 功能详细设计
如3.1.2中表格的分析所示，仅VRD/MCU/CPLD在注册时，可能注册StageSupported属性为true，其余固件注册StageSupported属性取值必定为false，因此只需要为注册为true的这三种固件注册RelatedItem属性即可。对于这几种固件，其在sr文件中均配置了`type`字段，用于指示该固件位于哪个单板上，因此可以在固件下发时，使用该字段进行查询，从而获取该固件所在单板的NodeId。为此，需要新实现一个函数`get_node_id_by_position`，VRD/MCU/CPLD固件下发时获取`type`字段，并结合下发的`position`入参，调用该函数获取单板的NodeId并保存。后续注册这些固件时，将保存的NodeId赋值给RelatedItem属性即可。需要注意的是最终生成的RelatedItem应当为一个redfish路径，例如“/redfish/v1/Chassis/1/Boards/BCU1CpuBoard1”，因此需要拼接NodeId以生成该属性。
### 3.2.3 开发者测试
<!--
增加模块接口：以活动图/流程图等形式明确模块内处理流程，针对模块处理流程中的分支进行覆盖
修改模块接口处理流程：覆盖修改影响流程分支
-->
同3.1.3章节
#### 3.2.3.1 单元测试
<!-- UT，主要是功能单元测试，测试对象是功能单元接口。UT测试设计要从黑盒（功能）角度设计，从输入(I)、处理（B）、预期输出（O）的角度进行用例分析设计，测试覆盖率仅作为反馈，用于分析哪些功能场景没有覆盖到，从而指导测试设计优化并补充测试用例 -->
不涉及
#### 3.2.3.2 集成测试
<!-- IT，主要是组件/模块内的集成测试，测试对象是模块/组件接口。IT测试设计将模块/组件当作黑盒测试，IT测试用例中禁止对组件/模块内部代码打桩，如果确实有少量场景难以构造，可以考虑在测试框架中统一打桩并提供接口供测试用例调用构造场景。
说明：API测试属于IT，其测试对象是微服务接口。
PCST，是指PC上的服务集成测试，测试对象是功能需求。PCST测试设计，要覆盖正常功能、异常功能和交叉功能，采用灰盒 -->
不涉及
## 3.3 注册固件匹配信息
### 3.3.1 功能实现设计
本功能主要任务为组件初始化时，根据固件对象在sr文件中配置的ComponentID、ComponentIDEx、UId属性，生成注册FirmwareInventory属性所需ComponentID、SubComponentID、TargetUIDs属性并注册给基础服务。
### 3.3.2 功能详细设计
当前代码流程中，各种固件调用接口注册固件清单的动作均是在收到sr文件中下发的固件对象后执行。因此在组件收到固件对象下发后，新增代码从下发的固件对象中获取sr文件配置的UId属性，并保存在变量中。注册固件清单时，代码即可读取之前保存的UId属性，注册给基础服务。对于ComponentID和SubComponentID属性，当前的大部分固件均未使用该字段，且sr文件中也没有配置。该字段最终用于本组件的固件升级时匹配使用，而本组件对于默认ComponentID和SubComponentID是全匹配的。因此对于sr文件中未配置的固件，只需固定注册该属性的默认值（0xff和0xffffffff）即可。

### 3.3.3 开发者测试
<!--
增加模块接口：以活动图/流程图等形式明确模块内处理流程，针对模块处理流程中的分支进行覆盖
修改模块接口处理流程：覆盖修改影响流程分支
-->
同3.1.3章节
#### 3.3.3.1 单元测试
<!-- UT，主要是功能单元测试，测试对象是功能单元接口。UT测试设计要从黑盒（功能）角度设计，从输入(I)、处理（B）、预期输出（O）的角度进行用例分析设计，测试覆盖率仅作为反馈，用于分析哪些功能场景没有覆盖到，从而指导测试设计优化并补充测试用例 -->
不涉及
#### 3.3.3.2 集成测试
<!-- IT，主要是组件/模块内的集成测试，测试对象是模块/组件接口。IT测试设计将模块/组件当作黑盒测试，IT测试用例中禁止对组件/模块内部代码打桩，如果确实有少量场景难以构造，可以考虑在测试框架中统一打桩并提供接口供测试用例调用构造场景。
说明：API测试属于IT，其测试对象是微服务接口。
PCST，是指PC上的服务集成测试，测试对象是功能需求。PCST测试设计，要覆盖正常功能、异常功能和交叉功能，采用灰盒 -->
不涉及

## 3.4 注册固件类型信息
### 3.4.1 功能实现设计
本功能主要任务为组件初始化时，根据固件的具体类型，生成FirmwareType属性注册到FirmwareInventory。
### 3.4.2 功能详细设计
当前代码流程中，各种固件的注册流程是分开进行的，在每一处注册固件的代码流程中，当前正在进行处理的固件是确定的。因此直接修改各处注册代码，根据当前处理的固件种类，直接将固定的固件类型（CPLD/VRD/SR/MCU/Retimer/VRD）赋值给FirmwareType即可。

### 3.4.3 开发者测试
<!--
增加模块接口：以活动图/流程图等形式明确模块内处理流程，针对模块处理流程中的分支进行覆盖
修改模块接口处理流程：覆盖修改影响流程分支
-->
同3.1.3章节
#### 3.4.3.1 单元测试
<!-- UT，主要是功能单元测试，测试对象是功能单元接口。UT测试设计要从黑盒（功能）角度设计，从输入(I)、处理（B）、预期输出（O）的角度进行用例分析设计，测试覆盖率仅作为反馈，用于分析哪些功能场景没有覆盖到，从而指导测试设计优化并补充测试用例 -->
不涉及
#### 3.4.3.2 集成测试
<!-- IT，主要是组件/模块内的集成测试，测试对象是模块/组件接口。IT测试设计将模块/组件当作黑盒测试，IT测试用例中禁止对组件/模块内部代码打桩，如果确实有少量场景难以构造，可以考虑在测试框架中统一打桩并提供接口供测试用例调用构造场景。
说明：API测试属于IT，其测试对象是微服务接口。
PCST，是指PC上的服务集成测试，测试对象是功能需求。PCST测试设计，要覆盖正常功能、异常功能和交叉功能，采用灰盒 -->
不涉及