openUBMC ASU管理特性设计说明书 ​

Copyright © 2026 openUBMC Community

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

改版记录

目录 ​

• 1. 特性概述
  • 1.1 目的
  • 1.2 范围
  • 1.3 特性需求列表
• 2. 需求场景分析
  • 2.1 特性需求来源与价值概述
  • 2.2 特性场景分析
  • 2.3 特性影响分析
• 3. 特性/功能实现原理
  • 3.1 目标
  • 3.2 总体方案
• 4. Use Case一实现：ASU模组管理模型定义
  • 4.1 设计思路
  • 4.2 约束条件
  • 4.3 详细实现
  • 4.4 关键接口
• 5. Use Case二实现：ASU模组上下电控制
  • 5.1 设计思路
  • 5.2 约束条件
  • 5.3 详细实现
  • 5.4 关键接口
• 6. Use Case三实现：ASU模组类型识别
  • 6.1 设计思路
  • 6.2 约束条件
  • 6.3 详细实现
  • 6.4 关键接口
• 7. Use Case四实现：ASU模组NVMe-MI通信通道建立
  • 7.1 设计思路
  • 7.2 约束条件
  • 7.3 详细实现
  • 7.4 关键接口
• 8. Use Case五实现：ASU模组槽位号同步
  • 8.1 设计思路
  • 8.2 约束条件
  • 8.3 详细实现
  • 8.4 关键接口
• 9. Use Case六实现：ASU模组硬盘资产管理
  • 9.1 设计思路
  • 9.2 约束条件
  • 9.3 详细实现
  • 9.4 关键接口
• 10. Use Case七实现：ASU模组CPU和内存资产管理
  • 10.1 设计思路
  • 10.2 约束条件
  • 10.3 详细实现
  • 10.4 关键接口
• 11. Use Case八实现：ASU模组产品资产管理
  • 11.1 设计思路
  • 11.2 约束条件
  • 11.3 详细实现
  • 11.4 关键接口
• 12. Use Case九实现：ASU模组温度采集
  • 12.1 设计思路
  • 12.2 约束条件
  • 12.3 详细实现
  • 12.4 关键接口
• 13. Use Case十实现：ASU模组GE MAC查询与切换
  • 13.1 设计思路
  • 13.2 约束条件
  • 13.3 详细实现
  • 13.4 关键接口
• 14. Use Case十一实现：ASU模组BIOS启动参数配置
  • 14.1 设计思路
  • 14.2 约束条件
  • 14.3 详细实现
  • 14.4 关键接口
• 15. Use Case十二实现：ASU模组UB启动速率配置
  • 15.1 设计思路
  • 15.2 约束条件
  • 15.3 详细实现
  • 15.4 关键接口
• 16. Use Case十三实现：ASU模组点灯控制
  • 16.1 设计思路
  • 16.2 约束条件
  • 16.3 详细实现
  • 16.4 关键接口
• 17. Use Case十四实现：ASU模组时间同步
  • 17.1 设计思路
  • 17.2 约束条件
  • 17.3 详细实现
  • 17.4 关键接口
• 18. Use Case十五实现：ASU模组功耗监控与配置
  • 18.1 设计思路
  • 18.2 约束条件
  • 18.3 详细实现
  • 18.4 关键接口
• 19. Use Case十六实现：ASU模组故障管理
  • 19.1 设计思路
  • 19.2 约束条件
  • 19.3 详细实现
  • 19.4 关键接口
• 20. Use Case十七实现：ASU模组固件升级
  • 20.1 设计思路
  • 20.2 约束条件
  • 20.3 详细实现
  • 20.4 关键接口
• 21. Use Case十八实现：ASU模组日志收集与可定位性
  • 21.1 设计思路
  • 21.2 约束条件
  • 21.3 详细实现
  • 21.4 关键接口
• 22. Use Case十九实现：ASU模组RAS故障管理
  • 22.1 设计思路
  • 22.2 约束条件
  • 22.3 详细实现
  • 22.4 关键接口
• 23. Use Case二十实现：ASU模组热插拔与主从管理
  • 23.1 设计思路
  • 23.2 约束条件
  • 23.3 详细实现
  • 23.4 关键接口
• 24. Use Case二十一实现：ASU模组复位与下电控制
  • 24.1 设计思路
  • 24.2 约束条件
  • 24.3 详细实现
  • 24.4 关键接口
• 25. Use Case二十二实现：ASU模组北向接口设计
  • 25.1 设计思路
  • 25.2 约束条件
  • 25.3 详细实现
  • 25.4 关键接口
• 26. Use Case二十三实现：ASU模组框SN同步
  • 26.1 设计思路
  • 26.2 约束条件
  • 26.3 详细实现
  • 26.4 关键接口
• 27. Use Case二十四实现：ASU管理功能编译裁剪
  • 27.1 设计思路
  • 27.2 约束条件
  • 27.3 详细实现
  • 27.4 关键接口
• 28. 可靠性&可用性设计
  • 28.1 冗余设计
  • 28.2 故障管理
  • 28.3 过载控制设计
• 29. 安全&隐私&韧性设计
  • 29.1 安全威胁分析及设计
  • 29.2 隐私风险分析
• 30. 特性非功能性质量属性相关设计
  • 30.1 可测试性
  • 30.2 可服务性
  • 30.3 可演进性
  • 30.4 兼容性
• 31. 参考资料清单

表目录

• 表1：特性场景相关性分析
• 表2：特性需求列表（高优先级）
• 表3：特性需求列表（中优先级）
• 表4：特性需求列表（低优先级）
• 表5：北向接口功能验证项

1. 特性概述 ​

openUBMC ASU管理特性旨在实现BMC对ASU（Acceleration Storage Unit）模组的全面带外管理能力。ASU模组是基于UB-EXP规范定义的灵衢生态存储标准组件，是集存储、网络、算力于一体的三合一芯片，面向数存、计算、华为云等多场景应用。

BMC通过NVMe-MI over MCTP over SMBus over LocalBus协议与ASU模组的IMU（Intelligent Management Unit）通信，实现ASU模组的识别、配置、监控、升级、故障管理等全生命周期管理能力，并通过Web、Redfish、SNMP、CLI、IPMI五大北向接口向运维人员提供统一的管理入口。

本特性支持12个ASU模组的并行管理、ASU模组的热插拔、存储场景下的主从BMC管理机制，以及自动配置同步、时间同步、温度监控、功耗管理、固件升级、RAS故障管理等核心功能。

1.1 目的 ​

本文档基于openUBMC ASU管理需求分析，对该特性的功能进行详细设计，明确系统架构、接口规范和实现方案，作为后续软件开发人员、测试人员和硬件集成工程师的技术指导文档。

文档详细描述了ASU模组的通信协议栈、识别初始化、配置同步、资产管理、温度监控、功耗管理、故障管理、固件升级、热插拔、主从管理等核心功能的设计与实现，为开发团队提供全面的技术规范和实现指南。

1.2 范围 ​

ASU管理特性主要包含以下功能模块和适用场景：

核心功能模块：

• ASU模组识别与初始化：通过EEPROM CSR信息识别ASU模组类型，建立NVMe-MI通信通道
• ASU模组上下电控制：支持ASU模组的上电、下电、复位控制
• ASU模组配置同步：自动同步UB启动速率、BIOS启动参数、功耗配置等
• ASU模组主机信息同步：自动同步槽位号和系统时间到ASU模组
• ASU模组资产管理：获取和管理ASU模组的资产信息、GE网口信息
• ASU模组温度监控：温度采集
• ASU模组功耗管理：实时功耗监控、封顶功耗配置
• ASU模组故障管理：健康状态监控、告警管理、RAS故障管理
• ASU模组固件升级：BIOS固件、ASU固件、数据盘/系统盘/IMU固件升级
• ASU模组日志收集：一键日志收集支持ASU模组日志、SPU OS黑匣子、UCP微码日志
• ASU模组热插拔：支持ASU模组的热拔插管理
• ASU模组主从管理：支持主BMC访问ASU，从BMC不访问ASU

适用场景分析：

1.3 特性需求列表 ​

高优先级需求（P0）：

中优先级需求（P1）：

低优先级需求（P2）：

2. 需求场景分析 ​

2.1 特性需求来源与价值概述 ​

需求来源背景：

openUBMC ASU管理特性需求来源于灵衢生态存储标准化和多场景统一管理的核心诉求：

1. 灵衢生态标准化需求：

   • ASU模组是基于UB-EXP规范定义的灵衢生态存储标准组件
   • 面向数存、计算、华为云等多场景应用，需要统一的管理框架
   • 需要标准化的BMC带外管理接口，支撑多场景灵活部署

2. 三合一芯片统一管理需求：

   • ASU模组是存、网、算三合一芯片，内部集成大容量存储（系统盘和数据盘）、网络接口（UBC、UBG、UBOE）、统一算力SPU
   • 需要一套管理方案覆盖存储、网络、算力三大能力的运维管理
   • 缺乏统一的带外管理标准，多维度运维成本高

3. 大规模并行管理需求：

   • 单机需要支持12个ASU模组的并行管理
   • 物理通道支持并行，需要软件层面充分发挥并行能力
   • 传统串行管理效率低下，无法满足大规模部署需求

4. 热插拔与高可用需求：

   • ASU模组支持热拔插，BMC需要正确处理热插拔事件
   • 热插入后需自动识别、初始化并纳入管理
   • 热拔出后需正确清理资源，不影响其他ASU模组

5. 主从BMC场景需求：

   • 存储场景有主从BMC，需支持主BMC访问ASU，从BMC不访问ASU
   • 主从切换时ASU管理需平滑过渡
   • 主从信息同步机制需与存储系列化交付对齐

6. 自动化运维需求：

   • ASU配置信息（UB启动速率、BIOS启动参数、功耗配置）需要自动同步
   • 系统时间需要定期同步，保障时间一致性
   • 减少人工干预，提升运维效率

7. 可定位性与可维护性需求：

   • ASU模组故障时需要快速定位，支持一键日志收集
   • RAS信息获取、硬盘故障诊断、数据重建恢复能力
   • SPU OS黑匣子、UCP微码日志等辅助定位手段

价值概述：

ASU管理特性通过标准化设计，全面提升了ASU模组的管理能力：

• 生态标准化：基于UB-EXP规范实现，支撑灵衢生态多场景应用
• 统一管理：存、网、算三合一芯片统一带外管理，降低运维复杂度
• 高效并行：支持12个ASU模组并行管理，充分发挥硬件通道并行能力
• 高可用：热插拔支持、主从BMC管理，保障业务连续性
• 自动化：配置自动同步、时间定期同步，减少人工干预
• 可定位：多维度日志收集、RAS故障管理，提升问题定位效率
• 北向一致：Web/Redfish/SNMP/CLI/IPMI五大北向接口统一管理入口

2.2 特性场景分析 ​

ASU管理特性的业务使用场景主要涵盖ASU模组的全生命周期管理：

主要应用场景：

1. ASU模组初始化场景：BMC启动后检测ASU在位，读取EEPROM CSR识别模组，建立NVMe-MI通信通道
2. ASU配置同步场景：自动同步UB启动速率、BIOS启动参数、功耗配置到ASU模组
3. ASU状态监控场景：定期监控温度、功耗、健康状态，根据告警信息做告警
4. ASU热插拔场景：ASU模组热拔插时正确处理资源回收与重建
5. ASU固件升级场景：通过BMC对ASU模组的BIOS、ASU固件进行带外升级
6. ASU故障处理场景：RAS故障诊断、硬盘故障诊断、数据重建恢复
7. 主从BMC切换场景：主从切换时ASU管理平滑过渡
8. ASU日志收集场景：一键日志收集ASU模组日志、SPU OS黑匣子、UCP微码日志

关键场景分析：

2.3 特性影响分析 ​

ASU管理特性作为openUBMC存储管理架构的重要扩展，对系统架构产生以下影响：

系统位置与周边接口：

• 通信协议层：NVMe-MI over MCTP over SMBus over LocalBus四层协议栈
• ASU模组识别：通过SMBus over LocalBus读取EEPROM CSR信息
• 管理通信：通过NVMe-MI over MCTP与ASU模组IMU交互
• 北向接口层：Web/Redfish/SNMP/CLI/IPMI五大管理接口
• 主从管理：主BMC管理ASU，从BMC不访问，主从信息同步
• 日志收集：扩展一键日志收集功能，增加ASU模组日志导出
• 固件管理：复用firmware_mgmt升级框架，支持ASU固件升级

关键约束与限制：

• 支持12个ASU模组并行管理，物理通道支持并行
• ASU模组热插拔时需正确处理资源回收和重建
• 存储场景主从BMC：主BMC访问ASU，从BMC不访问ASU
• 配置同步需校验配置有效性，配置一致时不重复配置
• UB启动速率和BIOS参数配置后需自动下电再上电生效
• 系统时间需定期同步，保障时间一致性
• 北向接口功能与历史版本保持一致

3. 特性/功能实现原理 ​

3.1 目标 ​

ASU管理特性设计目标是构建一个标准化、高并发、高可用的ASU模组带外管理框架：

主要目标：

1. 标准化：基于UB-EXP规范和NVMe-MI协议实现，满足灵衢生态标准要求
2. 高并发：支持12个ASU模组并行管理，充分发挥物理通道并行能力
3. 高可用：热插拔支持、主从BMC管理，保障业务连续性
4. 自动化：配置自动同步、时间定期同步，减少人工干预
5. 北向一致：Web/Redfish/SNMP/CLI/IPMI五大北向接口功能一致
6. 可定位：多维度日志收集、RAS故障管理，提升问题定位效率
7. 可扩展：面向数存、计算、华为云等多场景灵活适配

技术规格：

• 支持最多12个ASU模组并行管理，数据处理无异常
• ASU模组热插拔时设备树节点正确创建和清理
• 主从BMC切换时ASU管理平滑过渡
• 配置同步（UB启动速率、BIOS参数、功耗）自动完成
• 系统时间定期同步，保障时间一致性
• 告警、传感器等DFX功能与历史保持一致
• 各北向接口的ASU管理功能可测试、可对比验证

3.2 总体方案 ​

系统概述：

ASU管理特性通过分层架构实现BMC对ASU模组的全面带外管理。BMC启动后通过硬件检测UB-EXP部件在位，通过SMBus over LocalBus读取ASU模组EEPROM中的CSR信息完成模组识别；识别完成后通过NVMe-MI over MCTP over SMBus over LocalBus四层协议栈与ASU模组的IMU建立管理通信通道，实现配置同步、状态监控、固件升级、故障管理等全生命周期管理功能。

组网拓扑：

BMC通过LocalBus接入CPLD，由CPLD转换为SMB后进入FPGA；FPGA再扩展为12路I2C Master，分别管理12个ASU模组，实现物理通道级并行管理。

链路说明：

1. BMC → CPLD：BMC输出LocalBus总线
2. CPLD → FPGA：CPLD将LocalBus转换为SMB
3. FPGA → ASU：FPGA将SMB扩展为12路I2C Master，一对一管理12个ASU模组

协议流：

ASU模组与BMC之间的管理通信通过NVMe-MI over MCTP over SMBus协议实现，用于获取电子标签、网口信息及硬盘信息；主从切换由级联板的FPGA完成。

设备驱动层中的ASU驱动，其资产管理、网口管理、硬盘信息查询均通过协议库（NVMe-MI Over MCTP）下发至MCTP层，再经传输层I2C/SMBus与ASU模组交互。

协议分层说明：

1. 设备驱动层：ASU驱动提供资产管理、网口管理、硬盘信息等业务能力
2. 协议库：通过NVMe-MI Over MCTP封装管理命令，获取电子标签、网口信息及硬盘信息
3. MCTP层：完成消息路由与端点通信
4. 传输层：经I2C/SMBus承载MCTP报文；级联板FPGA负责主从切换后，接入对应ASU模组

架构设计原则：

1. 协议分层：通信协议栈按NVMe-MI/MCTP/SMBus/LocalBus严格分层，各层职责清晰
2. 并行管理：12个ASU模组独立管理实例，互不阻塞，充分发挥物理通道并行能力
3. 热插拔安全：ASU热插拔事件驱动，正确处理资源回收和重建
4. 主从透明：主从BMC管理机制对上层业务透明，主从切换时管理平滑过渡
5. 北向一致：五大北向接口数据同源，功能语义一致
6. 自动化优先：配置同步、时间同步等自动化处理，减少人工干预

4. Use Case一实现：ASU模组管理模型定义 ​

4.1 设计思路 ​

ASU模组管理模型定义是整个ASU管理特性的基础，定义了ASU模组在设备树中的对象模型和接口规范。ASU模组作为存、网、算三合一芯片，其管理模型需要覆盖ASU板卡（AsuCard）、UB网口（UBPort）、GE网口（GEPort）和NVMe盘（PCIeNVMe）四个核心对象。其中AsuCard、UBPort、GEPort构成ASU模组对象树；PCIeNVMe复用南向部件驱动模型，作为挂在System下的独立对象，不作为AsuCard的子对象。

模型设计原则：

1. DeviceCategory定义：ASU模组的设备类别定义为 AsuCard，用于设备树中统一标识
2. 对象分层：AsuCard为主对象，UBPort、GEPort为子对象，通过 :Parent 路径层级表达包含关系；PCIeNVMe不作为AsuCard子对象，独立挂在System下
3. 接口标准化：每个对象定义标准的能力集接口，覆盖ASU模组的全部管理能力
4. 能力可扩展：接口按功能维度划分，后续新增能力仅需扩展对应接口

ASU管理模型分层架构：

4.2 约束条件 ​

• DeviceCategory统一为 AsuCard，不得自行扩展
• AsuCard对象Path格式为 /bmc/dev/Systems/:SystemId/AsuCards/:Id，挂在System下
• UBPort对象Path格式为 :Parent/UBPort/:Id，作为AsuCard的子对象
• GEPort对象Path格式为 :Parent/GEPort/:Id，作为AsuCard的子对象
• PCIeNVMe对象Path格式为 /bmc/dev/Systems/:SystemId/PCIeNVMe/:Id，挂在System下，不作为AsuCard的子对象
• 接口名称和数据结构需严格遵循DDS规范定义

4.3 详细实现 ​

4.3.1 ASU管理接口模型定义 ​

• Schema：dds-v1
• Type：Component
• DeviceCategory：AsuCard
• Objects：AsuCard、UBPort、GEPort

4.3.2 AsuCard模型 ​

AsuCard模型代表ASU板卡，描述ASU板卡的基础信息和资产信息。

Path： /bmc/dev/Systems/:SystemId/AsuCards/:Id

AsuCard能力说明：

4.3.3 UBPort模型 ​

UBPort模型代表ASU卡上的UB网络端口，负责管理UB端口的网络功能和连接特性。

Path： :Parent/UBPort/:Id

UBPort能力说明：

4.3.4 GEPort模型 ​

GEPort模型代表ASU卡上的GE网络端口，负责管理GE端口的网络功能和连接特性，包含GE MAC地址属性。

Path： :Parent/GEPort/:Id

GEPort能力说明：

4.3.5 PCIeNVMe模型 ​

PCIeNVMe模型代表ASU卡内部的NVMe盘（系统盘和数据盘），复用已有的PCIeNVMe南向驱动模型，实现NVMe盘的发现、注册和管理。PCIeNVMe作为挂在System下的独立对象，不作为AsuCard的子对象；与ASU模组的关联关系通过Drive对象映射建立。

Path： /bmc/dev/Systems/:SystemId/PCIeNVMe/:Id

PCIeNVMe能力说明：

5. Use Case二实现：ASU模组上下电控制 ​

6. Use Case三实现：ASU模组类型识别 ​

6.1 设计思路 ​

ASU模组类型识别通过加载CSR配置信息完成。CSR加载支持两种方式：读取EEPROM加载和预置文件加载，根据实际部署场景选择。

两种CSR加载方式对比：

6.2 约束条件 ​

• 读取EEPROM加载方式需遵守天池规范，ASU模组需具备对应的UID
• 预置CSR文件加载方式将CSR内容存放到BMC包中，无法通过CSR升级单独更新
• CSR加载成功后才能进行后续的NVMe-MI通信通道建立

6.3 详细实现 ​

6.3.1 读取EEPROM加载 ​

1. BMC启动后通过硬件检测ASU部件在位
2. 通过i2c通道访问ASU模组EEPROM
3. 按天池规范读取EEPROM中的CSR信息，使用对应UID进行校验
4. 解析CSR内容，识别ASU模组类型
5. 后续可通过CSR升级流程更新EEPROM中的CSR内容

遗留问题：读eeprom通过i2c over localbus是否支持，需要框架确认？ 答：支持，读eeprom与总线。

6.3.2 预置CSR文件加载 ​

1. 将CSR内容预先打包存放到BMC包中
2. BMC启动后从BMC包内读取预置CSR文件
3. 解析CSR内容，识别ASU模组类型
4. 无需UID校验
5. CSR内容更新需随BMC版本升级一起完成

7. Use Case四实现：ASU模组NVMe-MI通信通道建立 ​

7.1 设计思路 ​

ASU模组与BMC之间的管理通信通过NVMe-MI over MCTP协议实现。通信通道的建立依赖MctpBinding配置和Endpoint配置，使用mctpd组件提供的能力创建endpoint进行通信：

1. MctpBinding配置（BMC主机信息）：配置BMC主机侧的MCTP绑定信息，作为通信的源端
2. Endpoint配置（ASU目的设备信息）：配置ASU目的设备的Endpoint信息，作为通信的目的端
3. mctpd组件：使用mctpd组件提供的能力创建endpoint，完成MCTP通信端点的注册和路由
4. 通道建立：endpoint创建成功后，BMC即可通过NVMe-MI over MCTP与ASU模组IMU进行通信

7.2 约束条件 ​

• MctpBinding需正确配置BMC主机信息
• Endpoint需正确配置ASU目的设备信息
• mctpd组件需正常运行，提供endpoint创建能力
• 每个ASU模组对应一个独立的MCTP endpoint，12个ASU模组需创建12个独立endpoint
• 通信通道建立依赖ASU模组已完成类型识别（CSR加载）

7.3 详细实现 ​

1. 根据ASU模组在位情况，配置MctpBinding（BMC主机信息），作为通信源端
2. 配置Endpoint（ASU目的设备信息），作为通信目的端
3. 调用mctpd组件接口创建MCTP endpoint，注册通信端点
4. mctpd组件完成MCTP路由发现和endpoint绑定
5. endpoint创建成功后，建立NVMe-MI over MCTP通信通道
6. 通道建立后，BMC可通过NVMe-MI命令与ASU模组IMU交互

8. Use Case五实现：ASU模组槽位号同步 ​

8.1 设计思路 ​

ASU模组槽位号同步通过上一级连接器（Connector）的Slot属性传递实现。当Connector加载ASU的CSR配置时，将Connector的Slot属性值传递到ASU模组保存，使ASU模组感知自身所在槽位位置。

同步流程：

1. Connector作为ASU模组的上一级连接器，持有Slot槽位号属性
2. Connector加载ASU的CSR配置时，读取自身的Slot属性
3. 将Slot属性值通过设备树传递到ASU模组
4. ASU模组保存槽位号，用于资产信息标识和位置定位

8.2 约束条件 ​

• 槽位号同步依赖Connector的Slot属性正确配置
• Connector加载ASU CSR配置时触发槽位号同步
• ASU模组热插拔后需重新同步槽位号
• 槽位号需与物理槽位一一对应

8.3 详细实现 ​

1. Connector加载ASU的CSR配置，初始化ASU模组对象
2. 读取Connector的Slot属性值
3. 通过设备树将Slot属性值写入ASU模组对象
4. ASU模组保存槽位号到设备树节点
5. 槽位号同步完成后，ASU模组资产管理信息中包含槽位位置

9. Use Case六实现：ASU模组硬盘资产管理 ​

9.1 设计思路 ​

ASU模组内部提供大容量存储能力（系统盘和数据盘），NVMe盘的管理走南向部件驱动方案，复用已有的PCIeNVMe模型。PCIeNVMe对象挂在System下（Path为 /bmc/dev/Systems/:SystemId/PCIeNVMe/:Id），不作为AsuCard的子对象；通过在ASU配置Drive对象建立与NVMe盘的映射关系，硬盘告警配置到ASU的CSR中，北向接口的硬盘显示继续复用从Drive相关资源树获取。

设计要点：

1. 复用PCIeNVMe模型：NVMe盘管理走南向部件驱动方案，复用已有的PCIeNVMe南向驱动模型，避免重复开发；PCIeNVMe独立挂在System下，不作为AsuCard子对象
2. Drive对象映射：在ASU的CSR中配置Drive对象，建立ASU与NVMe盘之间的映射关系，替代原父子对象绑定关系
3. 告警配置到CSR：硬盘相关告警配置到ASU的CSR中，由ASU模组统一管理告警
4. 北向复用资源树：北向接口的硬盘显示继续复用从Drive相关资源树获取，保持接口一致性

9.2 约束条件 ​

• NVMe盘管理必须走南向部件驱动方案，复用PCIeNVMe模型
• PCIeNVMe对象Path格式为 /bmc/dev/Systems/:SystemId/PCIeNVMe/:Id，挂在System下，不得作为AsuCard的子对象
• ASU的CSR中需配置Drive对象，用于NVMe盘的映射
• 硬盘告警需配置到ASU的CSR中
• 北向接口硬盘显示从Drive相关资源树获取
• ASU模组热插拔时需正确处理Drive对象及关联PCIeNVMe对象的创建和清理

9.3 详细实现 ​

9.3.1 NVMe盘管理（复用PCIeNVMe模型） ​

1. ASU模组内部的NVMe盘通过南向部件驱动方案注册到设备树，PCIeNVMe对象Path为 /bmc/dev/Systems/:SystemId/PCIeNVMe/:Id（挂在System下，不作为AsuCard的子对象）
2. 复用已有的PCIeNVMe南向驱动模型，实现NVMe盘的发现、注册和管理
3. PCIeNVMe对象实现 bmc.dev.PCIeDevice、bmc.dev.PCIeDevice.PCIeFunction、bmc.dev.PCIeDevice.Status、bmc.dev.NVMe、bmc.dev.NVMe.Management、bmc.dev.NVMe.ProductInfo、bmc.dev.NVMe.MultiRecord、bmc.dev.NVMe.Status 接口
4. PCIeNVMe驱动负责NVMe盘的状态监控、健康查询、指标采集等

9.3.2 Drive对象映射 ​

1. 在ASU的CSR中配置Drive对象，描述ASU内部NVMe盘的信息
2. Drive对象与PCIeNVMe南向驱动发现的NVMe盘（Path：/bmc/dev/Systems/:SystemId/PCIeNVMe/:Id）建立映射关系
3. 通过Drive映射关系（而非对象父子层级）关联管理ASU模组内部的NVMe盘

9.3.3 硬盘告警管理 ​

1. 硬盘相关告警（如温度告警、健康告警、预测性故障等）配置到ASU的CSR中
2. ASU模组通过NVMe-MI获取硬盘告警信息
3. 根据CSR中配置的告警规则，触发告警上报

9.3.4 北向接口硬盘显示 ​

1. 北向接口（Web/Redfish/SNMP/CLI/IPMI）的硬盘显示继续复用从Drive相关资源树获取
2. Drive资源树中的硬盘数据由PCIeNVMe南向驱动同步
3. 北向接口无需感知ASU模组的存在，直接从Drive资源树获取硬盘信息

10. Use Case七实现：ASU模组CPU和内存资产管理 ​

11. Use Case八实现：ASU模组产品资产管理 ​

11.1 设计思路 ​

ASU模组产品资产管理通过ASU驱动从ASU模组获取产品信息，并更新到AsuCard对象下。产品信息通过带外协议获取，保障数据来源可信。

设计要点：

1. 带外获取：ASU驱动通过NVMe-MI over MCTP协议从ASU模组获取产品信息
2. 设备树同步：获取到的产品信息更新到AsuCard对象下的 bmc.dev.Fru 接口
3. 北向复用：北向接口从AsuCard对象获取产品资产信息，保持数据源统一

11.2 约束条件 ​

• 产品信息必须通过NVMe-MI over MCTP带外协议从ASU模组获取，不得从主机侧获取
• 产品信息需更新到AsuCard对象的 bmc.dev.Fru 接口
• ASU模组热插拔后需重新获取产品信息

11.3 详细实现 ​

1. ASU模组通信通道建立后，ASU驱动通过NVMe-MI over MCTP协议从ASU模组获取产品信息
2. 将获取到的产品信息更新到AsuCard对象的 bmc.dev.Fru 接口
3. 北向接口（Web/Redfish/SNMP/CLI/IPMI）从AsuCard对象获取产品资产信息

12. Use Case九实现：ASU模组温度采集 ​

12.1 设计思路 ​

ASU模组温度采集通过带外协议（NVMe-MI over MCTP）定期从ASU模组IMU获取温度传感器数据，更新到设备树供北向接口查询和散热系统使用。ASU模组作为高功耗存网算三合一芯片，温度监控是保障模组稳定运行的基础能力。

设计要点：

1. 带外采集：通过NVMe-MI over MCTP带外协议从ASU模组IMU获取温度数据
2. 定期轮询：BMC定期轮询ASU模组温度传感器，保障温度数据实时性
3. 设备树同步：采集到的温度数据更新到设备树，供散热系统和北向接口使用
4. 并行采集：12个ASU模组温度采集互不阻塞，充分发挥物理通道并行能力

12.2 约束条件 ​

• 温度数据必须通过带外协议从ASU模组获取，不得从主机侧获取
• 温度采集需定期执行，保障数据实时性
• 12个ASU模组温度采集需并行执行，互不阻塞
• ASU模组热插拔后需重新纳入温度采集

12.3 详细实现 ​

1. ASU模组通信通道建立后，启动温度采集任务
2. 通过NVMe-MI over MCTP带外协议定期向ASU模组IMU查询温度传感器数据
3. 将采集到的温度数据更新到设备树对应节点
4. 散热系统从设备树获取ASU模组温度数据，纳入整机散热策略
5. 北向接口（Web/Redfish/SNMP/CLI/IPMI）从设备树获取温度数据展示

13. Use Case十实现：ASU模组GE MAC查询 ​

13.1 设计思路 ​

GE MAC查询实现：网口的模型定义跟随ASU管理对象模型定义使用GEPort模型，实现 bmc.dev.NetworkPort 接口，包含GE MAC地址属性。通过带外协议（NVMe-MI over MCTP）从ASU模组获取GE MAC地址，更新到设备树供外部接口获取。

设计要点：

1. 复用GEPort模型：网口模型跟随ASU管理对象模型定义中的GEPort模型，Path为 :Parent/GEPort/:Id（作为AsuCard的子对象）
2. 实现NetworkPort接口：GEPort实现 bmc.dev.NetworkPort 接口，包含GE MAC地址属性
3. 带外获取：通过带外协议从ASU模组获取GE MAC地址信息
4. 设备树同步：获取到的GE MAC地址更新到设备树，供北向接口查询

13.2 约束条件 ​

• 网口模型必须使用GEPort模型，实现 bmc.dev.NetworkPort 接口
• GE MAC地址通过带外协议从ASU获取，不得从主机侧获取
• GE MAC地址需更新到设备树，保证数据源唯一
• ASU模组热插拔后需重新获取GE MAC地址

13.3 详细实现 ​

1. ASU模组识别完成后，初始化GEPort模型对象
2. GEPort对象实现 bmc.dev.NetworkPort 接口，包含GE MAC地址属性
3. 通过NVMe-MI over MCTP带外协议向ASU模组IMU查询GE MAC地址
4. 将查询到的GE MAC地址更新到设备树GEPort节点
5. 北向接口（Web/Redfish/SNMP/CLI/IPMI）从设备树获取GE MAC地址信息

14. Use Case十一实现：ASU模组BIOS启动参数配置 ​

14.1 设计思路 ​

新定义BIOS管理对象模型，通过NVMe-MI over MCTP协议设置和查询BIOS启动参数

设计要点：

1. 模型定义：BIOS管理对象路径以ASU板卡模型的路径为前缀，接口定义上需要尽量通用，兼顾服务器系统或其他小系统的BIOS
2. 带外获取：通过带外协议设置和查询BIOS启动参数
3. 设备树同步：获取到的BIOS启动参数更新到设备树，供北向接口查询；设备树提供方法给北向接口设置BIOS启动参数

14.2 约束条件 ​

• 约束数据来源只能通过设备树，保证来源唯一
• ASU模组热插拔后需重新获取BIOS启动参数

14.3 详细实现 ​

1. ASU模组识别完成后，初始化BIOS管理对象
2. 通过NVMe-MI over MCTP带外协议向ASU模组查询BIOS启动参数，更新到设备树上。包括优先启动项、生效模式、默认启动项
3. 实现设备树接口，当北向调用设备树方法时通过NVMe-MI over MCTP带外协议对ASU模组配置BIOS启动参数，包括优先启动项、生效模式

15. Use Case十二实现：ASU模组UB启动速率配置 ​

15.1 设计思路 ​

UB启动速率配置复用UBPort模型的 bmc.dev.NetworkPort 接口，新增UB启动速率配置方法。用户设置UB启动速率后，通过带外协议设置到ASU模组。

设计要点：

1. 复用UBPort模型：UB启动速率配置复用UBPort模型的 bmc.dev.NetworkPort 接口，无需新增模型
2. 新增配置方法：在 bmc.dev.NetworkPort 接口上新增UB启动速率配置方法
3. 带外设置：用户设置UB启动速率后，通过带外协议下发到ASU模组

15.2 约束条件 ​

• UB启动速率配置必须复用UBPort模型的 bmc.dev.NetworkPort 接口
• 用户设置UB启动速率后需通过带外协议下发到ASU
• 配置同步需校验配置有效性，配置一致时不重复配置

15.3 详细实现 ​

1. 用户通过北向接口设置UB启动速率
2. 在UBPort模型的 bmc.dev.NetworkPort 接口上调用UB启动速率配置方法
3. 通过NVMe-MI over MCTP带外协议将UB启动速率设置下发到ASU模组
4. ASU模组保存UB启动速率配置

16. Use Case十三实现：ASU模组点灯控制 ​

16.1 设计思路 ​

ASU模组点灯控制复用已有的Led模型定义，分为故障灯控制和定位灯控制两类。每个ASU按照独立System管理，对应的资源树路径为 /bmc/kepler/Systems/:SystemId/Leds/:ID。点灯依赖上一级单板的CPLD实现，chassis组件通过CPLD对各个System独立进行点灯场景处理。

故障灯与定位灯的区别：

设计要点：

1. 复用Led模型：故障灯和定位灯均复用已有的Led模型定义，无需新增模型
2. 独立System管理：每个ASU模组按照独立System管理，LED资源归属对应System
3. 资源树路径：LED对象资源树路径为 /bmc/kepler/Systems/:SystemId/Leds/:ID
4. 依赖上级CPLD：点灯依赖上一级单板的CPLD实现，chassis组件通过CPLD对各个System独立进行点灯场景处理
5. 故障灯自动控制：故障灯根据单个ASU模组的健康状态自动控制，无需北向接口干预
6. 定位灯北向可控：定位灯支持通过北向接口控制，用户可远程触发定位操作

16.2 约束条件 ​

• 点灯控制必须复用已有Led模型定义
• 每个ASU模组按独立System管理，LED对象归属对应System
• LED对象资源树路径为 /bmc/kepler/Systems/:SystemId/Leds/:ID
• 点灯依赖上一级单板的CPLD实现
• chassis组件需通过CPLD对各个System独立进行点灯场景处理，互不干扰
• 故障灯无北向接口控制，仅根据ASU模组健康状态自动控制
• 定位灯支持北向接口控制，用户可通过北向接口下发定位指令
• 故障灯控制基于单个ASU模组的健康状态，不与其他ASU模组关联

16.3 详细实现 ​

1. 每个ASU模组作为独立System注册到资源树
2. 在对应System下创建LED对象，路径为 /bmc/kepler/Systems/:SystemId/Leds/:ID
3. LED对象复用已有的Led模型定义，支持故障灯和定位灯控制
4. 故障灯控制：
   • chassis组件监控单个ASU模组的健康状态
   • 当ASU模组健康状态异常（故障/告警）时，chassis组件自动触发故障灯点亮
   • 当ASU模组健康状态恢复正常时，chassis组件自动触发故障灯熄灭
   • 故障灯控制无北向接口，用户无法直接控制
5. 定位灯控制：
   • 用户通过北向接口下发定位指令到指定ASU模组的LED对象
   • chassis组件接收定位指令后，通过上一级单板的CPLD下发点灯指令
   • 定位灯点亮后按策略持续或定时熄灭
6. chassis组件通过CPLD对各个System的LED独立进行点灯场景处理，互不干扰

17. Use Case十四实现：ASU模组时间同步 ​

18. Use Case十五实现：ASU模组功耗监控与配置 ​

19. Use Case十六实现：ASU模组故障管理 ​

20. Use Case十七实现：ASU模组固件升级 ​

20.1 设计思路 ​

服务器管理南向接口技术要求已定义了通用固件升级接口bmc.dev.Upgrade。固件升级能力应当围绕此接口定义展开

20.2 约束条件 ​

1. 涉及升级功能的部分应当在对应接口定义中包含bmc.dev.Upgrade，包括BIOS、ASU模组、盘等
2. 固件大小可能较大，需要在实现升级方法时考虑分帧处理

20.3 详细实现 ​

1. 通过NVMe-MI over MCTP带外协议的固件升级命令字实现bmc.dev.Upgrade的Upgrade方法。实现时考虑分帧处理
2. 北向接口通过调用该方法触发升级，将升级状态、升级进度、升级结果等更新到设备树上，供北向接口显示

21. Use Case十八实现：ASU模组日志收集与可定位性 ​

22. Use Case十九实现：ASU模组RAS故障管理 ​

23. Use Case二十实现：ASU模组热插拔与主从管理 ​

24. Use Case二十一实现：ASU模组复位与下电控制 ​

25. Use Case二十二实现：ASU模组北向接口设计 ​

25.1 设计思路 ​

ASU模组作为存、网、算三合一芯片，其北向管理接口需要覆盖网口管理、硬盘管理、BIOS管理、上下电管理、指示灯管理五大管理能力。本Use Case基于Redfish标准协议，采用两层拓扑结构（Enclosure → Blade）设计ASU模组的北向接口。

架构设计原则：

1. 遵循Redfish标准：使用DMTF规范的Chassis Contains/ContainedBy层级建模
2. 一个BMC一个框：每个BMC独立管理一个框及其内部所有ASU模组
3. 资源隔离：每个ASU模组的网口/硬盘/BIOS/上下电/灯各自独立，互不干扰
4. 代码复用：现有NetworkAdapters、Drives、Power、Bios等接口模板可直接复用
5. 向后兼容：单ASU场景下保持现有 Chassis/1 的行为不变

两层拓扑结构：

┌──────────────────────────────────────────────────────────────┐
│  Enclosure (框)                                               │
│  /redfish/v1/Chassis/1                                       │
│  ChassisType: "Enclosure"                                    │
│  Links.Contains → [ASU-1, ASU-2, ... , ASU-12]              │
│  Managers/1 → BMC (管理整个框)                                │
│  Power / Thermal (框级共享资源)                                │
│                                                              │
│  ├── ASU-1 (部件)                                             │
│  │   /redfish/v1/Chassis/ASU-1                               │
│  │   ChassisType: "Blade"                                    │
│  │   Links.ContainedBy → Chassis/1                           │
│  │   Links.ComputerSystems → Systems/ASU-1                   │
│  │   NetworkAdapters / Drives / IndicatorLED                 │
│  │                                                           │
│  ├── ASU-2 (部件)                                             │
│  │   /redfish/v1/Chassis/ASU-2                               │
│  │   ...（结构同 ASU-1）                                       │
│  │                                                           │
│  └── ASU-12 ...                                              │
│                                                              │
│  BMC: /redfish/v1/Managers/1                                 │
│  系统n: /redfish/v1/Systems/ASU-n                            │
└──────────────────────────────────────────────────────────────┘

25.2 约束条件 ​

• 每个ASU模组对应一个独立的Chassis（ChassisType=Blade）和一个独立的ComputerSystem
• 框级资源（电源、散热）归属Chassis/1（Enclosure），所有ASU模组共享
• 光模块（Transceivers）在框级汇聚，ASU Port通过Oem链接引用
• 单ASU场景下Chassis/1同时承担Enclosure+Blade角色，行为不变
• 现有代码中路径硬编码为 Chassis/1 的需统一改为参数化 Chassis/{chassisid}

25.3 详细实现 ​

25.3.1 Chassis分层设计 ​

框级 Chassis (Enclosure)：

{
    "@odata.id": "/redfish/v1/Chassis/1",
    "@odata.type": "#Chassis.v1_26_0.Chassis",
    "Id": "1",
    "Name": "Enclosure",
    "ChassisType": "Enclosure",
    "PowerState": "On",
    "Status": { "Health": "OK", "State": "Enabled" },
    "Power": { "@odata.id": "/redfish/v1/Chassis/1/Power" },
    "Thermal": { "@odata.id": "/redfish/v1/Chassis/1/Thermal" },
    "ThermalSubsystem": { "@odata.id": "/redfish/v1/Chassis/1/ThermalSubsystem" },
    "PowerSubsystem": { "@odata.id": "/redfish/v1/Chassis/1/PowerSubsystem" },
    "Sensors": { "@odata.id": "/redfish/v1/Chassis/1/Sensors" },
    "Links": {
        "Contains": [
            { "@odata.id": "/redfish/v1/Chassis/ASU-1" },
            { "@odata.id": "/redfish/v1/Chassis/ASU-2" }
        ],
        "ManagedBy": [
            { "@odata.id": "/redfish/v1/Managers/1" }
        ]
    }
}

ASU模组级 Chassis (Blade)：

{
    "@odata.id": "/redfish/v1/Chassis/ASU-1",
    "@odata.type": "#Chassis.v1_26_0.Chassis",
    "Id": "ASU-1",
    "Name": "ASU Module 1",
    "ChassisType": "Blade",
    "PowerState": "On",
    "IndicatorLED": "Off",
    "LocationIndicatorActive": false,
    "Status": { "Health": "OK", "State": "Enabled" },
    "NetworkAdapters": { "@odata.id": "/redfish/v1/Chassis/ASU-1/NetworkAdapters" },
    "Drives": { "@odata.id": "/redfish/v1/Chassis/ASU-1/Drives" },
    "PCIeDevices": { "@odata.id": "/redfish/v1/Chassis/ASU-1/PCIeDevices" },
    "EnvironmentMetrics": { "@odata.id": "/redfish/v1/Chassis/ASU-1/EnvironmentMetrics" },
    "Links": {
        "ContainedBy": { "@odata.id": "/redfish/v1/Chassis/1" },
        "ComputerSystems": [
            { "@odata.id": "/redfish/v1/Systems/ASU-1" }
        ],
        "ManagedBy": [
            { "@odata.id": "/redfish/v1/Managers/1" }
        ]
    }
}

System 级 (ComputerSystem)：

{
    "@odata.id": "/redfish/v1/Systems/ASU-1",
    "@odata.type": "#ComputerSystem.v1_0_0.ComputerSystem",
    "Id": "ASU-1",
    "Name": "ASU Module 1 System",
    "PowerState": "On",
    "Bios": { "@odata.id": "/redfish/v1/Systems/ASU-1/Bios" },
    "Storage": { "@odata.id": "/redfish/v1/Systems/ASU-1/Storage" },
    "EthernetInterfaces": { "@odata.id": "/redfish/v1/Systems/ASU-1/EthernetInterfaces" },
    "Processors": { "@odata.id": "/redfish/v1/Systems/ASU-1/Processors" },
    "Memory": { "@odata.id": "/redfish/v1/Systems/ASU-1/Memory" },
    "Links": {
        "ManagedBy": [
            { "@odata.id": "/redfish/v1/Managers/1" }
        ],
        "Chassis": [
            { "@odata.id": "/redfish/v1/Chassis/ASU-1" }
        ]
    },
    "Actions": {
        "#ComputerSystem.Reset": {
            "target": "/redfish/v1/Systems/ASU-1/Actions/ComputerSystem.Reset"
        }
    }
}

25.3.2 网口管理接口 ​

25.3.3 硬盘管理接口 ​

25.3.4 BIOS管理接口 ​

25.3.5 上下电管理接口 ​

25.3.6 指示灯管理接口 ​

25.3.7 其他关联接口 ​

25.3.8 资源归属与共享策略 ​

25.3.9 与现有代码的兼容策略 ​

单ASU兼容：

• 单ASU时：Chassis/1 同时承担 Enclosure + Blade 角色，行为不变
• 多ASU时：Chassis/1 仅作为框级容器，ASU模组通过 Chassis/{ASUId} 访问

路径参数化：

现有代码中部分路径硬编码为 Chassis/1，需统一改为参数化：

// 改造前
"@odata.id": "/redfish/v1/Chassis/1/NetworkAdapters/${ProcessingFlow[1]/Destination/ID}"

// 改造后
"@odata.id": "/redfish/v1/Chassis/${Uri/chassisid}/NetworkAdapters/${ProcessingFlow[1]/Destination/ID}"

Chassis.json Links 扩展：

框级 Chassis (ChassisType=Enclosure)：

"Links": {
    "Contains": "${Statements/GetContains()}",
    "ManagedBy": [
        { "@odata.id": "/redfish/v1/Managers/1" }
    ]
}

ASU模组级 Chassis (ChassisType=Blade)：

"Links": {
    "ContainedBy": { "@odata.id": "/redfish/v1/Chassis/1" },
    "ComputerSystems": [
        { "@odata.id": "/redfish/v1/Systems/${Uri/chassisid}" }
    ],
    "ManagedBy": [
        { "@odata.id": "/redfish/v1/Managers/1" }
    ]
}

25.4 关键接口 ​

待补充

26. Use Case二十三实现：ASU模组框SN同步 ​

26.1 设计思路 ​

框SN（Serial Number）同步实现将整机的框序列号同步到ASU模组，用于ASU模组标识其所属的物理框。框SN同步涉及三个环节：

1. 框SN读取：框SN从EEPROM存放的电子标签中读取
2. 设备树传递：产业APP通过设备树将框SN设置到ASU驱动
3. 带外下发：ASU驱动监听到框SN变化后，通过NVMe-MI over MCTP协议将框SN设置到ASU模组

设计要点：

1. 电子标签读取：框SN来源于EEPROM电子标签，数据源唯一可信
2. 设备树驱动：产业APP通过设备树将框SN设置到ASU驱动，实现解耦
3. 变化监听：ASU驱动监听设备树中框SN属性变化，触发同步流程
4. 带外同步：框SN变化后通过NVMe-MI over MCTP带外协议下发到ASU模组

26.2 约束条件 ​

• 框SN必须从EEPROM电子标签读取，不得使用其他数据源
• 产业APP通过设备树设置框SN到ASU驱动，ASU驱动不主动读取框SN
• ASU驱动需监听设备树中框SN属性变化，变化后才触发同步
• 框SN同步通过NVMe-MI over MCTP带外协议下发到ASU模组
• 框SN同步依赖ASU模组NVMe-MI通信通道已建立

26.3 详细实现 ​

1. 框SN从EEPROM存放的电子标签中读取，由电子标签管理模块负责
2. 产业APP从电子标签获取框SN后，通过设备树将框SN设置到ASU驱动节点
3. ASU驱动监听设备树中框SN属性变化，检测到框SN更新
4. ASU驱动通过NVMe-MI over MCTP带外协议将框SN设置到ASU模组
5. ASU模组保存框SN，用于标识其所属物理框
6. 12个ASU模组并行同步框SN，互不阻塞

27. Use Case二十四实现：ASU管理功能编译裁剪 ​

27.1 设计思路 ​

ASU管理功能通过Option编译宏控制实现功能裁剪，支持不带ASU模组的 BMC版本编译。裁剪范围覆盖南向驱动和北向接口两个层面：

裁剪范围：

1. 南向驱动裁剪：不携带ASU驱动代码和ASU的CSR配置文件
2. 北向接口裁剪：Web和Redfish中新增的ASU相关接口全部裁剪掉

设计要点：

1. Option编译宏：通过统一的编译宏（如 feature_asu）控制ASU管理功能的编译开关
2. 南向裁剪：关闭编译宏后，ASU驱动代码和ASU的CSR配置文件不编入BMC包
3. 北向裁剪：关闭编译宏后，Web前端和Redfish后端中ASU相关的接口、页面、资源全部裁剪
4. 零影响：裁剪后BMC其他功能不受影响，不产生编译错误或运行时异常

27.2 约束条件 ​

• 裁剪通过编译宏控制，不支持运行时动态开关
• 南向裁剪必须同时裁剪ASU驱动代码和ASU的CSR配置文件，不可部分裁剪
• 北向裁剪必须覆盖Web和Redfish中所有ASU相关接口，不可遗漏
• 裁剪后不得产生编译错误、链接错误或运行时依赖异常
• 裁剪后BMC其他设备管理功能不受影响

27.3 详细实现 ​

1. 编译宏定义：在构建系统中定义 feature_asu 编译宏，默认开启，关闭时不编译ASU相关功能
2. 南向驱动裁剪：
   • 关闭 feature_asu 后，ASU驱动源码不参与编译
   • ASU的CSR配置文件不打包到BMC镜像中
   • DDS模型文件（AsuCard相关）不加载
3. 北向接口裁剪：
   • Redfish：ASU相关的Redfish资源（Chassis下的Blade资源、ASU网口、硬盘、BIOS等）不注册，相关URI不可访问
   • Web：ASU相关的Web页面、菜单入口、前端组件不打包，界面无ASU相关入口
4. 依赖隔离：ASU相关代码与其他模块通过接口解耦，裁剪后不产生悬空依赖
5. 编译验证：裁剪编译后通过自动化编译验证，确保无编译错误和运行时异常

27.4 关键接口 ​

28. 可靠性&可用性设计 ​

28.1 冗余设计 ​

• 物理通道隔离：BMC 经 LocalBus → CPLD → SMB → FPGA 扩展为 12 路独立 I2C Master，各 ASU 模组一对一管理，单通道异常不影响其他 ASU
• 主从 BMC 冗余：存储场景支持主从 BMC；主 BMC 访问 ASU，从 BMC 不访问 ASU；主从切换由级联板 FPGA 完成，管理平滑过渡
• 独立管理实例：12 个 ASU 模组各自独立管理实例与独立 MCTP endpoint，实例间互不阻塞，避免单点拖垮全局管理
• 独立 System/LED 资源：每个 ASU 按独立 System 管理 LED 等资源，故障灯/定位灯场景互不干扰
• 编译裁剪兜底：无 ASU 的产品通过 feature_asu 裁剪南向驱动与北向接口，避免无效代码路径影响整机可用性

28.2 故障管理 ​

• 通信故障检测：NVMe-MI over MCTP over SMBus 通信超时/失败时记录日志，支持有限次重试；持续失败后上报告警，不影响其他 ASU 管理
• 识别与通道建立异常：EEPROM CSR 读取失败或 MCTP endpoint 创建失败时，该 ASU 进入不可管理态并告警，不阻塞其余模组初始化
• 热插拔异常处理：热插入后自动识别、建链、同步资产/槽位/配置；热拔出后清理设备树节点、Drive/PCIeNVMe 关联及 endpoint，残留资源回滚清理
• 硬盘与健康告警：硬盘告警配置于 ASU CSR，经 NVMe-MI 获取后按规则上报；故障灯根据单模组健康状态由 chassis 经上级 CPLD 自动控制
• RAS 与可定位：支持 RAS 故障诊断、数据重建相关能力，以及一键日志收集（ASU 模组日志、SPU OS 黑匣子、UCP 微码日志）
• 配置同步保护：UB 启动速率、BIOS 参数、功耗等配置同步前校验有效性，配置一致时不重复下发，降低误配风险
• 主从切换异常：切换过程中从 BMC 不得访问 ASU；切换失败时保持原访问策略并告警，避免双主争用通道

故障检测与恢复流程：

故障恢复策略说明：

28.3 过载控制设计 ​

• 并行上限管控：最多支持 12 个 ASU 并行管理，按物理 I2C Master 通道天然限流，避免软件侧无界并发
• 实例隔离调度：温度采集、资产同步、框 SN 同步等任务按模组并行且互不阻塞，单模组阻塞不扩散
• 配置防抖：配置一致不重复下发；需下电再生效的配置按既定流程执行，避免频繁电源操作
• 采集频率控制：温度、功耗等动态数据按周期轮询，静态资产信息以事件驱动（上电/热插/建链）为主，降低总线占用
• 北向查询降压：五大北向接口数据同源设备树，避免每次北向请求都穿透到 ASU 侧重复采数
• 升级窗口控制：固件升级复用 firmware_mgmt 框架，按模组串行/受控并行策略执行，防止升级洪峰占满管理通道

29. 安全&隐私&韧性设计 ​

29.1 安全威胁分析及设计 ​

安全防护分层：

主要威胁与防护：

防护要点：

• 资产、GE MAC、温度、硬盘信息等必须走带外协议，不得从主机侧旁路获取
• 高危操作（上下电、复位、固件升级、定位灯）纳入鉴权与审计
• 主从场景下访问策略对上层透明，但底层严格执行“仅主访问”
• 点灯依赖上级单板 CPLD，由 chassis 按 System 独立下发，避免跨模组误控

29.2 隐私风险分析 ​

本特性主要管理 ASU 硬件资产、网口、硬盘、温度、功耗与日志，不直接处理终端用户个人身份信息，整体隐私风险较低。需关注：

• 设备标识信息：电子标签/FRU、框 SN、GE MAC、盘序列号等属于设备标识，日志导出与北向展示遵循最小必要原则
• 运维日志：一键日志可能包含模组运行细节与微码日志，导出、存储与对外传递需按运维安全规范管控
• 配置与策略数据：BIOS 启动参数等可能影响启动安全策略，变更需鉴权并审计，避免未授权泄露或篡改

30. 特性非功能性质量属性相关设计 ​

30.1 可测试性 ​

覆盖并对比验证以下场景，且五大北向接口（Web/Redfish/SNMP/CLI/IPMI）行为可对齐：

30.2 可服务性 ​

• 可定位：支持 ASU 模组日志、SPU OS 黑匣子、UCP 微码日志一键收集，配合 RAS 信息缩短排障路径
• 可观测：通信失败、热插拔、健康告警、主从切换等关键事件具备日志与告警
• 可运维：定位灯支持远程触发；故障灯随健康状态自动指示，降低现场找模成本
• 可裁剪交付：无 ASU 整机可通过编译宏裁剪，降低包体与无效服务面

30.3 可演进性 ​

• 模型可扩展：AsuCard/UBPort/GEPort 按能力集接口划分，新增能力优先扩展接口而非重构对象树
• 协议分层稳定：NVMe-MI / MCTP / SMBus / LocalBus 分层清晰，便于替换或增强单层实现
• 南向复用：PCIeNVMe、Led、firmware_mgmt 等复用既有框架，减少重复建设
• 北向可演进：Enclosure→Blade 两层拓扑支持从单 ASU 平滑扩展到 12 ASU；路径参数化避免硬编码
• 特性开关演进：以 feature_asu 为总开关，后续可继续拆分细粒度 feature_xxx 而不破坏裁剪主流程

30.4 兼容性 ​

• 单 ASU 兼容：单 ASU 场景下保持现有 Chassis/1 行为不变
• 北向兼容：Web/Redfish/SNMP/CLI/IPMI 对 ASU 管理功能语义一致、数据同源；告警/传感器等 DFX 与历史保持一致
• 模型兼容：PCIeNVMe 挂在 /bmc/dev/Systems/:SystemId/PCIeNVMe/:Id，不作为 AsuCard 子对象，通过 Drive 映射关联，兼容南向盘管理既有方案
• 无 ASU 产品兼容：关闭 feature_asu 后不影响其他设备管理功能
• 存储主从兼容：主从访问策略与存储系列化交付对齐，主从切换不破坏既有管理约定

31. 参考资料清单 ​

1. NVMe Management Interface（NVMe-MI）规范
2. MCTP / SMBus 相关协议规范
3. DMTF Redfish Chassis / ComputerSystem 相关 Schema 规范
4. openUBMC 南向部件驱动开发规范与 DDS 模型规范
5. openUBMC 北向接口裁剪特性设计说明书
6. openUBMC firmware_mgmt 固件升级框架说明
7. openUBMC 多层级定制与 bingo 构建工具文档