硬件管理与接口收敛

异构AI平台的管理难点是语义和生命周期不一致：同一张NIC在资产系统里是一张卡，在网络系统里是若干端口，在主机里又是PCIe功能与操作系统接口；固件更新被接受、写入完成和重置后真正生效，发生在不同时间。规模化管理需要让这些对象及其状态能够被发现、关联和验证。

OCP的Baseline、Ethernet NIC和Service Baseline使用Redfish组织远程管理行为；OBMF-ICP则把设备内部的启动和管理接口收敛到可发现的逻辑通道。前者回答“管理什么、如何调用”，后者回答“底层组件怎样通信”。二者共同决定平台能否跨供应商、跨代际运行。S032 pp. 5–8 S033 pp. 6–9 S034 pp. 5–9 S069 pp. 11–17

建立物理、逻辑与管理三种对象身份#

Redfish用Chassis表示物理实体，用ComputerSystem表示逻辑计算实体，用Manager表示管理控制器。FRU序列号、资产标签和定位灯属于物理维护语境，系统电源状态属于计算系统，控制器固件、管理IP和重启属于管理器。它们通过链接关联，客户端应从资源发现与链接遍历建立映射。S032 pp. 8–13, 20–23

这个划分解决了两个常见操作歧义。重置BMC与重置计算系统有不同影响；某个机壳告警与某个逻辑主机的作业故障也需要通过真实包含关系才能关联。基础管理清单覆盖FRU、定位灯、健康、电源、功耗、温度、风扇、日志及控制器信息，并将任务分别列为Mandatory或Recommended，便于形成供应商互操作测试。S032 pp. 6–7

功率和热资源还有版本演进。指南同时说明较旧Power/Thermal资源与新的PowerSubsystem/ThermalSubsystem资源路径，后者是演进方向。管理平台需要做能力发现与模型适配，将读取结果统一到内部语义，保留原始资源身份和单位；直接把某个样例URI写死为全部设备的路径，会增加换代成本。S032 pp. 13–18

NIC资源图把通信路径映射回真实硬件#

读下面的资源图时，从NetworkAdapter沿着Port、NetworkDeviceFunction和PCIe对象向下追踪，再看它们与系统EthernetInterface之间的链接。同一块卡上的物理端口、虚拟化功能和主机接口各有独立状态，问题定位需要保留这几层身份。

原图：Usage Guide for Ethernet NIC，Figure 1，物理第9页。S033 pp. 8–9

NetworkAdapter提供整卡信息、控制器能力、固件版本及PCIe设备链接；Port表达链路技术、介质、速率、宽度、信号与链路状态；NetworkDeviceFunction表达Ethernet功能和物理端口分配，并连接PCIeFunction及操作系统接口。这使带外管理能在主机软件失效时继续读取设备结构。S033 pp. 10–18

遥测也按对象分层。卡级指标、功能级收发字节与帧、端口级错误和丢弃，以及光收发器相关读数，分别回答不同问题。比如端口链路仍为Up、某个功能流量停止、PCIe连接退化，指向的排查路径不同。将所有读数展平成“网卡健康”，会丢失与训练Fabric及光链路遥测衔接所需的上下文。S033 pp. 20–23

配置必须区分运行值与待生效值。NIC资源可通过@Redfish.Settings指向Settings对象，并声明支持的应用时机，例如OnReset。编排器应记录期望配置、待生效配置和当前运行配置，安排重置，再回读端口和功能状态。固件更新同样可以指定目标设备与OnReset时机，更新成功的判据应包含重置后的版本与功能验证。S033 pp. 9, 18–19, 23–24

服务基线让自动化获得稳定的行为契约#

Service Baseline将管理接口的运行行为纳入统一模型：通过Service Root发现服务与资源，通过EventService创建订阅，通过LogService读取持久事件，通过UpdateService管理固件清单及升级，通过SessionService和TaskService管理会话与长任务。证书管理还覆盖CSR生成、证书读取与替换，为管理端身份维护提供标准入口。资源结构、操作方法与状态组合起来，才构成可自动化的服务。S034 pp. 7–12, 18–26

事件订阅与日志承担互补角色。订阅把变化推送给监控者，日志保留可回查记录；事件中的MessageId、OriginOfCondition和LogEntry将机器可读故障类型、具体传感器及记录关联起来。客户端可用ServiceConditions读取当前仍然存在的条件，恢复连接后重新建立现状，再与历史事件对齐。S034 pp. 13–15, 18–19, 22–23

长任务的接受与完成也要分开。Task资源提供TaskState、TaskMonitor、StartTime及Messages，适合跟踪固件升级等异步操作。平台方可以据此构建“提交—观察—完成—验证”的状态机，并将超时、失败和重试与设备生命周期关联。RegisteredClient描述客户端类型和其管理的资源，帮助多套监控、配置系统表达各自责任范围。S034 pp. 23–26

用一轮固件变更检验管理模型是否闭合#

可以用NIC升级作为平台接入的完整演练。首先通过资源图确认实体卡、端口、功能与主机接口，再读取固件清单、当前运行版本和支持的更新方法；随后将升级目标与生效时间绑定，交给变更编排。更新服务支持的方法和目标设备均应通过实际资源发现，避免把另一型号的升级路径移植过来。S033 pp. 10–18, 23–24 S034 pp. 19–21

收到任务后，管理系统持续观察状态和消息；需要重置时，先把设备对应的作业或服务移到可维护状态，再执行约定的重置。恢复后重新发现资源、核对固件版本、读取运行设置，并验证端口状态、功能映射及错误指标。若原Settings仍处于待生效状态，或功能数量发生变化，变更记录应保留这一差异，供后续处理。这里的编排序列是依据指南能力构建的平台实现方法。

这轮操作还检验身份是否稳定。设备替换后，同一个机位可能具有相同管理地址，却有新的序列号和不同PCIe功能；控制器恢复出厂后，原会话和订阅也可能失效。资产、连接和服务发现应分别重新确认，再把新状态并入机队记录。服务基线提供账户、会话、网络配置、订阅和注册客户端对象，使这类重新接入可以按明确资源操作执行。S032 pp. 9–11 S034 pp. 10–18, 23–26

同样的验收可以推广到多供应商接入：用一套管理任务检查对象是否可发现、设置是否可回读、事件能否定位原对象，以及失败能否落到具体Task或日志。互操作性由这些实际行为支撑，接口版本和profile则为每项行为提供共同依据。S032 pp. 5–8 S033 pp. 6–9

OBMF-ICP将多根传统管理接口收敛为逻辑通道#

CPU、BMC、GPU和NIC之间存在GPIO、UART、I2C、SPI、TPM、RTC、IPMI及启动代码等不同通信需求。OBMF-ICP用同一物理连接上的多个逻辑通道承载这些用途，包含MMIO方式和面向接口优化的通道，使不同处理器架构能够复用管理软件与桥接实现。S069 pp. 11–16, 19–21

下面的原图先看BMC的位置，再看被管理的CPU与GPU。OBMF-ICP中的Host恒为BMC，Device是被管理组件；某条通道上的Producer/Consumer角色则由提供服务的一方决定。例如BMC可向处理器提供RTC服务，处理器也可向BMC提供自身FRU信息。

原图：OBMF-ICP 1.0.0，Figure 3，物理第18页。S069 pp. 17–20

Channel 0是发现与配置入口，由Device暴露并从早期启动保持可用。BMC先读取协议版本、设备身份、通道类型和各通道角色；若处理器需要从BMC获取启动镜像，BMC必须先准备并启用对应服务，处理器才能继续启动。这个握手把原来隐含在板级信号中的启动依赖变成可发现契约。S069 pp. 22–24, 58–65

并发模型要求每个通道只保留一个等待响应的请求，通道之间独立处理，因此Flash访问等待不应阻塞RTC或GPIO服务。协议支持应用消息最高64 kB，实际最大请求/响应大小由设备和通道能力声明；Channel 0的MMIO Short读写要求至少64 B请求与响应payload，这是发现入口的特定要求。S069 pp. 12–13, 23–26, 58

配置存在持久制造配置与运行覆盖两层。运行时写入先缓冲，再由Apply动作生效，读取Configuration Valid与Health确认结果；接口复位后运行覆盖被丢弃，设备恢复持久配置。编排系统应在复位后重新发现和对账，防止把上一轮内存中的期望状态误认为设备现状。S069 pp. 59–65

传输绑定决定消息边界、故障恢复和实际时延#

OBMF-ICP要求底层保证消息交付、不重复、有序和完整性，具体绑定负责实现这些保证。USB原生绑定强制实现Bulk IN与Bulk OUT，Interrupt端点为可选，用于适合通知的通道；一个OBMF消息可跨多个Bulk包，但当前绑定每个USB transfer只承载一个OBMF消息。长度恰为最大包大小整数倍时，发送端使用ZLP结束transfer，接收端据此核对消息边界。S069 pp. 13–14 S068 pp. 8–14

驱动不能只验证正常路径。USB绑定建议持续安排Bulk IN读以降低通知等待，发生STALL后先清除Endpoint Halt，再按需要升级到Port或Bus Reset，并清空相关管线与状态。由于多个服务共享传输，恢复过程还要重新确认各通道的配置与可用性，并将影响向上报告。S068 pp. 14, 17–18

接口收敛也让保护集中到一个连接点。系统可使用SPDM等既有安全机制保护管理流量，并针对不同通道实施隔离；TPM通道按其安全会话机制保护。吞吐、优先级、时延和隔离应一起验证，尤其是启动镜像访问、GPIO通知和固件维护同时发生的情况。S069 pp. 79–81 密钥和信任设计见平台数据与密钥安全，故障信息到维护动作的闭环见可靠性服务。