在数字化浪潮中，算力设备是推动各行业发展的核心驱动力。作为一款架构先进、开发友好且标准开放的开源管理软件，openUBMC通过社区共建共享的南北向生态，正逐步成为算力设备管理领域的重要力量。

openUBMC致力于建立全量开源的服务器部件适配库，形成业界领先的部件兼容能力。在 25.09 版本中，openUBMC推出了全新的部件管理架构，引入了“部件驱动”概念。 我们将推出系列技术文章，深入剖析“部件驱动”概念的原理及其对服务器运维管理的深远影响，欢迎持续关注。

BMC如何管理南向部件

在了解南向部件驱动之前，我们先回顾BMC是如何管理南向部件的。通常管理能力分为以下三层次：

1. 静态数据管理： 识别部件并展示其静态数据（如 VPD、电子标签、PCIe 四元组信息等），满足运维对硬件资产的基本管理需求。
2. 部件带外能力： 通过北向接口将部件的带外管理能力（如传感器数据、事件信号、固件升级、日志收集等）传递给网管软件和运维人员。
3. 智能运维能力： 基于海量硬件数据进行分析与聚合，提升单节点自管理效率，实现更智能化的运维。
   

BMC管理南向部件的三层次

随着服务器行业的快速发展，静态数据管理已相对成熟，部件带外能力和智能运维能力成为关注焦点。然而，由于部件的多样性、硬件特性及协议差异，带外管理能力参差不齐，适配工作耗费大量精力。例如，不同厂商和型号的硬件可能需要通过IPMB、SMBus或MCTP等协议获取属性，导致适配代码复杂且高度耦合。

以下是一个典型的硬件适配代码示例，反映了当前的问题：

function network_adapter:get_propA_from_card()

    -- 适配厂商B时，propA完全不支持

    if self.manufacturer == "VendorB" then

        return "Unsupported"

    end

    -- 特定机型需通过IPMB协议获取propA

    if chassis_use_ipmb then

        return self:get_propA_from_card_via_ipmb()

    end

    -- ModelB仅支持SMBus协议

    if self.model == "ModelB" then

        return self:get_propA_from_card_via_smbus()

    elseif self.model == "ModelA2" then

        -- ModelA2的MCTP协议存在缺陷，需特殊处理

        return self:get_propA_from_card_via_mctp_special()

    end

    -- 默认使用MCTP协议

    return self:get_propA_from_card_via_mctp()

end

硬件迭代速度加快，同一厂商不同型号的部件能力差异显著，适配代码与硬件型号高度耦合，导致维护成本激增。开发团队在新硬件发布时需投入大量资源进行适配和测试，同时为避免影响已有硬件兼容性，需额外进行回归测试。这种现状不仅阻碍软件快速迭代，还限制了BMC智能运维能力的扩展。

为解决这一问题，openUBMC 提出了更灵活的硬件适配方案——“部件驱动”，旨在通过抽象层解耦硬件适配代码，降低维护成本，提升开发效率，为软件的可持续发展奠定基础。

南向部件驱动的创新

1.当前架构的挑战

在现有架构中，硬件的抽象管理模型是基于部件类型构建，不同厂商和型号的设备共用同一模型，导致硬件差异集中在单一模型中。此外，业务单元按APP分配，同一部件的多种业务功能分散在多个APP 中，造成代码耦合，适配逻辑缺乏内聚性。

当前架构示意图

为应对这些挑战，openUBMC的部件驱动架构采取了以下三步优化：

1. 代码集中化： 将同一部件的适配代码集中管理，确保硬件层面的唯一性，并为同类别硬件扩展不同厂商和型号的管理抽象模型。开发者既可以将适配代码与一个具体的型号绑定，实现更加深度的部件差异化适配能力，也可以创建一个通用的适配代码，实现部件即插即用。
2. 边界清晰化： 明确部件驱动与APP的职责划分，定义哪些功能由部件驱动实现，哪些由APP完成，部件驱动聚焦于将部件的能力和属性与BMC业务所需要的能力对接，APP则聚焦于如何基于部件驱动提供的能力和属性实现更加智能的运维特性。
3. 代码插件化： 适配代码变更频繁，且数量会越来越多，通过采用微内核架构模式，将部件管理框架和部件管理适配分离，通过统一的框架去加载和运行这些适配代码片段。框架可以提供多样的、丰富的能力，进一步简化适配代码逻辑，降低差异化适配成本。

2.部件驱动的定义

部件驱动借鉴了操作系统中硬件驱动的开发模式，允许硬件厂商针对自家部件开发独立驱动程序，确保其在 BMC 环境中正常运行。这种模式不仅降低了整机集成商的适配负担，还赋予硬件厂商更大的自主性，减少了对 BMC 软件集成的依赖。

部件驱动架构示意图

通过部件驱动，openUBMC 实现了硬件适配的模块化管理，使新硬件的适配过程更加高效，同时确保了现有硬件的兼容性。

3.部件管理接口模型

为规范化部件驱动，指导其具体的实现和约束，openUBMC定义了部件管理接口模型，通过模型化方式描述了部件以及其器件的各种功能。

部件管理接口模型继承了资源协作接口模型的大部分定义，但更聚焦于软件对部件的描述，资源协作接口模型更多是从BMC整体系统对每个业务特性的描述。

部件管理接口模型与实际部件对应关系

openUBMC定义的部件管理接口模型从BMC业务需求出发，确保了接口的高可用性与可解释性。 例如，传感器数据的获取、固件升级的触发等功能均通过明确定义的接口实现，便于长期维护与扩展。

展望

服务器南向部件驱动是openUBMC架构在硬件适配领域的全新探索，期望通过部件驱动的方式进一步优化BMC部件适配的开发效率与灵活性。围绕这套新架构体系，openUBMC社区将持续推动以下方面的发展：

1. 深化生态协作： 通过部件驱动模式，部件厂商可以更灵活地参与BMC生态，开发并维护其专属驱动。这种去中心化的协作模式将加速部件适配进程，降低整机集成商的开发负担，同时增强部件厂商对自身产品的控制力，形成更开放、多元的产业生态。
2. 扩展智能化运维： 部件驱动的模块化设计为BMC智能运维能力的扩展提供了坚实基础。基于统一的接口模型，BMC可以更高效地聚合多源硬件数据，专注于运维优化与提升，实现故障预测、能效优化等高级功能，进一步提升算力设备的运维效率。
3. 标准规范建设： 推动部件接口管理模型标准化与接口定义规范化，既能为南向部件驱动的开发提供产业指导，也能使部件驱动接入不同的BMC实现方案。
4. 社区认证体系： 基于部件接口管理模型，社区将建设完整的部件兼容性认证体系，包括测试用例、方案审核、安全检查等能力。同时推动产业上下游加入认证体系，促成新的服务器BMC部件适配交付模式。
5. 社区驱动创新： openUBMC社区的开放性为部件驱动的持续优化提供了无限可能。开发者可以基于标准化的接口模型贡献代码、分享适配经验，推动对新协议和新硬件的支持，形成技术创新的正向循环。

下篇详解：部件驱动框架的设计理念

敬请期待

加入我们，共建高效、开放、可持续的算力设备管理生态！

https://www.openubmc.cn

任何想法、问题，欢迎通过社区论坛、Issue、SIG例会进行交流！

GitCode仓库：https://gitcode.com/openUBMC/

社区论坛：https://discuss.openubmc.cn