两个BCU 的connect bom id 都指向同一个文件，导致重复名称sensor 会有两个

交流互助区
1

1.当BCU 有两块，Connector_BCU_01 Connector_BCU_02 的bomid 都指向同一个sr 文件，那这个回到只有两个同名的sensor ,如果需要只保留一个，怎么处理吗

例如：指向的同一个sr 文件，有sensor 配置如下：

“DiscreteSensor_BMCBoot”: {
“OwnerId”: 32,
“OwnerLun”: 0,
“EntityId”: “<=/Entity_MainBoard.Id”,
“EntityInstance”: “<=/Entity_MainBoard.Instance”,
“Initialization”: 99,
“Capabilities”: 64,
“SensorType”: 29,
“ReadingType”: 111,
“SensorName”: ”BMC_Boot”,
“AssertMask”: 1,
“DeassertMask”: 0,
“DiscreteMask”: 1,
“Unit”: 192,
“BaseUnit”: 0,
“ModifierUnit”: 0,
“DiscreteType”: 1,
“RecordSharing”: 1,
“Reading”: 0
}

所以展示时会有两个BMC_Boot, 这个怎么可以只保留一个，以你为BMC_Boot 有两个，这个怎么理解尼？有两个BMC 启动完成传给两个基础板吗？

2

答案内容由AI生成，仅供参考：

:white_check_mark: 五、总结与建议

项目 建议
根本原因 SR文件中使用了静态 SensorName，未结合 Slot 或 BCUIndex 实现差异化
是否应有两个BMC_Boot 是，但必须名称不同，以区分所属BCU
推荐方案 修改SR文件，将 SensorName 改为 "BCU${Slot}_BMC_Boot" 或 "BMC_Boot_BCU${BCUIndex}"
替代方案 使用不同BOM ID对应不同SR文件，或在初始化阶段控制加载逻辑（仅限共享资源）
验证方式 检查 D-Bus 接口、IPMI SEL 输出、传感器列表是否显示两个唯一命名的传感器

:white_check_mark: 最佳实践建议：

  • 所有在多实例硬件上部署的SR文件，若包含传感器、LED等资源，推荐一律使用 Slot / BCUIndex / SystemId 等变量进行动态命名
  • 避免在SR中使用纯静态 SensorName，除非资源是全局唯一的

如有必要，可参考 bmc.kepler.Systems.DiscreteSensor 接口和 GetDiscreteSensorList 方法验证最终输出结果是否符合预期。

点击此处查看详细分析解答

关于双BCU连接器BOM ID指向同一SR文件导致Sensor名称重复的问题分析与解决方案

根据您提出的问题，当前系统存在两个BCU（Baseboard Control Unit）模块（Connector_BCU_01 和 Connector_BCU_02），它们的 BOM ID 均指向同一个 SR（Self-describing Record，硬件自描述）文件。这导致系统加载该SR配置时，会为每个BCU实例重复创建相同的传感器资源（如 SensorName: "BMC_Boot"），从而出现两个同名传感器“BMC_Boot”的现象。

下面从问题成因、影响分析以及解决建议三个方面进行详细说明。

:magnifying_glass_tilted_left: 一、问题成因

1. SR文件的BOM ID设计原则

在 openUBMC 系统中：

  • SR 文件命名通常遵循 BOM_UID.sr 的格式，其中：
    • BOM 表示 Bill of Materials（物料清单编号）
    • UID 是设备唯一标识符
  • BOM ID 相同通常意味着硬件设计相同或高度相似，因此系统允许多个物理单元复用同一个SR文件。

:white_check_mark: 合理场景：如果两块BCU是完全一致的硬件板卡，使用同一个SR文件是合理的。

然而，当SR文件中包含静态定义的资源（如传感器 SensorName）且未根据上下文区分实例时，就会导致多个BCU加载后产生重复的资源命名。

2. SensorName 的生成机制

根据知识库信息：

  • SensorName 是一个字符串属性，用于人眼识别和日志记录，例如 "BMC_Boot"。
  • 它通常是静态配置在SR文件中的，但如果采用动态表达式（如 "${Slot}" 或 "BCU${Slot} VCC_12V0_1"），可以通过绑定变量实现差异化命名。

您提供的示例中：

"SensorName": "BMC_Boot"

这是一个静态字符串，不包含任何动态占位符（如 ${Slot} 或 ${SystemId}），因此无论多少个BCU加载此SR文件，都会生成完全相同的传感器名。

:warning: 二、影响分析

1. 展示层问题：同名传感器无法区分

  • 在监控系统、IPMI SEL日志、Web UI等界面中，出现两个名为 BMC_Boot 的传感器，无法判断其归属哪一个BCU。
  • 可能引发运维误判，尤其是告警触发时无法准确定位故障来源。

2. 资源冲突风险

  • 如果这些传感器注册到统一的 D-Bus 接口路径下（如 /xyz/openbmc_project/sensors/discrete/BMC_Boot），则后加载的会覆盖前一个，导致资源冲突或部分传感器不可见。
  • 即使路径支持多实例（通过 Object Path + Instance 区分），前端展示仍可能无法正确映射。

3. 是否表示两个BMC启动？

:red_question_mark: “有两个BMC启动完成传给两个基础板吗？”

不是。

  • 这里的“BMC_Boot”传感器并不表示“BMC已启动”，而是指“监控某块主板上BMC Boot状态的传感器”。
  • 在双BCU架构中，可能只有一个主BMC控制器，但它需要监控两个不同BCU板卡的启动状态。
  • 因此应该有两个不同名称的传感器，例如：
    • BCU1_BMC_Boot
    • BCU2_BMC_Boot

否则无法区分哪个BCU完成了启动。

:white_check_mark: 三、解决方案建议

:white_check_mark: 方案一：【推荐】修改SR文件，使用动态SensorName（结合 Slot / BCUIndex）

将原静态 SensorName 改为动态命名，依赖 Slot 或 BCUIndex 进行差异化。

示例修改前：

"SensorName": "BMC_Boot"

修改后：

"SensorName": "BCU${Slot}_BMC_Boot"

或使用 BCUIndex：

"SensorName": "BMC_Boot_BCU${BCUIndex}"

:white_check_mark: 说明：

  • ${Slot} 通常由 Connector_BCU_X.Slot 提供（如 Slot=1 或 Slot=2）
  • BCUIndex 是系统用来标识具体BCU实例的关键字段（见知识图谱 BCUIndex 实体）

这样，两个BCU加载时，生成的传感器名称分别为：

  • BCU1_BMC_Boot
  • BCU2_BMC_Boot

实现唯一可识别性。

:white_check_mark: 方案二：为不同BCU使用不同的SR文件（差异化BOM ID）

若两个BCU虽硬件相似但功能不同，建议为其分配不同的BOM ID，并准备独立的SR文件。

例如：

  • 14220247_0001.sr → 用于 Connector_BCU_01
  • 14220247_0002.sr → 用于 Connector_BCU_02

每个SR文件内部可单独配置 SensorName 或其他参数，避免冲突。

:white_check_mark: 优点：彻底隔离配置，适用于异构场景
:cross_mark: 缺点：增加维护成本，不适合对称硬件

:white_check_mark: 方案三：通过 UnitConfiguration 控制只加载一次（仅适用于共享资源）

如果您认为 BMC_Boot 状态在整个系统中只需监控一次（比如只有一个实际BMC），那么可以通过以下方式控制加载行为：

方法：

  • 在 UnitConfiguration 中设置条件判断逻辑，仅让某个特定 BCUIndex == 1 或 Slot == 1 的实例加载该传感器。
  • 或者通过 cfg 配置表中的 bcu_index 字段，在初始化阶段 (c_unit_configuration:init) 决定是否注册该资源。

:red_exclamation_mark: 注意：此方法仅适用于真正共享的全局资源（如同一个BMC只启动一次）。如果不满足该前提，会导致信息缺失。

:pushpin: 四、技术依据支持

以下是基于知识图谱的关键实体与关系支撑：

实体 说明
BCUIndex 标识具体的BCU实例，值通常为 1 或 2，用于区分主从板
bcu_index 在 cfg 对象中镜像 BCUIndex，可供脚本使用
UnitConfiguration 定义系统级资源配置，支持动态解析与初始化
c_unit_configuration:init Lua方法，负责初始化配置，可加入条件逻辑
SensorName 支持动态字符串，如 "BCU${Slot} VCC_12V0_1" 已有先例

此外，现有系统中已有类似实践：

  • BCU${Slot}_V_VCC_12V0_1 就是动态传感器命名的典型用法
  • Entity_MainBoard 作为传感器拥有者，也可结合其 Instance 属性区分上下文

:white_check_mark: 五、总结与建议

项目 建议
根本原因 SR文件中使用了静态 SensorName，未结合 Slot 或 BCUIndex 实现差异化
是否应有两个BMC_Boot 是，但必须名称不同，以区分所属BCU
推荐方案 修改SR文件，将 SensorName 改为 "BCU${Slot}_BMC_Boot" 或 "BMC_Boot_BCU${BCUIndex}"
替代方案 使用不同BOM ID对应不同SR文件，或在初始化阶段控制加载逻辑（仅限共享资源）
验证方式 检查 D-Bus 接口、IPMI SEL 输出、传感器列表是否显示两个唯一命名的传感器

:white_check_mark: 最佳实践建议：

  • 所有在多实例硬件上部署的SR文件，若包含传感器、LED等资源，推荐一律使用 Slot / BCUIndex / SystemId 等变量进行动态命名
  • 避免在SR中使用纯静态 SensorName，除非资源是全局唯一的

如有必要，可参考 bmc.kepler.Systems.DiscreteSensor 接口和 GetDiscreteSensorList 方法验证最终输出结果是否符合预期。