整机PSR配置指导书
整机PSR配置指导书
修订记录
| 日期 | 修订版本 | 修改描述 |
|---|---|---|
| 2025/06/14 | V1.0 | 初版完成 |
| 2025/07/16 | V1.1 | 刷新传感器capabilities属性和Scanner ScanEnabled属性配置规范 |
| 2025/07/28 | V1.2 | 新增防抖配置指导链接 |
| 2025/07/30 | V1.3 | 刷新目录(3.3节后续为BMC软件维护) |
| 2025/08/19 | V1.4 | 新增能效组件管理 |
| 2025/08/28 | V1.5 | 新增sr升级流程 |
| 2025/09/03 | V1.6 | 新增BDF config |
| 2025/11/12 | V1.7 | 新增PSR构建策略,补充BDFconfig配置方法 |
| 2025/12/12 | V1.8 | 新增920B代码仓拆分方式说明 |
| 2026/01/28 | V1.9 | AirCoolingConfig对象新增MaxAllowedSpeedPercent字段配置说明 |
| 2026/02/07 | V2.0 | 支持BMC作为PCIe设备的bdf属性自发现 |
| 2026/02/13 | V2.1 | PowerStrategy对象新增NonCappedStaticPowerWatts字段配置说明 |
| 2026/06/16 | V2.2 | CSR 目录合规刷新:脱敏内部信息,移除页眉拟制信息 |
[TOC]
当前的920B的CSR分为两部分,硬件CSR和软件CSR,硬件CSR为存放在硬件EEPROM中的CSR内容,软件CSR为存放在BMC中的CSR内容,软件CSR文件名一般以soft结尾,形如****_soft.sr,正式使用时应将两部分合并起来看,同一对象的属性可能会拆开成两部分,一部分属性在硬件csr中,一部分属性在软件csr中。920B的CSR在构建出CSR包时,仅将硬件CSR打包放入EEPROM中;在构建BMC包时,会将硬件CSR与软件CSR合并,并内置于BMC中,此时如果硬件CSR与软件CSR中有重复对象,对象的属性会以软件CSR为准;在服务器实际运行过程中,BMC会比较内置CSR与从EEPROM中获取的CSR版本号,当BMC内置的CSR版本号高时,直接使用BMC内置CSR,当EEPROM中的版本号高时,会将内置CSR与EEPROM中的CSR进行合并,此时如果BMC内置CSR与EEPROM里的CSR有重复对象,以EEPROM里的对象为准。 其他新开发的CSR按照version.sr,mgmt_model.sr,basic_info.sr拆分,构建时统一打包到EEPROM中。
0 PSR定义及整体框架
0.1 定义
PSR是站在软件的角度来定义整机硬件“是什么,有什么,能做什么”,其主要是从整机视角配置整机所需要的描述信息及功能。
0.2 PSR结构说明
一个完整的PSR由三个部分组成,第一部分为FormatVersion、DataVersion、DataType组成的版本描述信息,第二部分为管理拓扑:ManagementTopology,第三部分为管理对象:Objects。
{
"FormatVersion" : "3.00", //PSR代次版本号,当前PSR代次版本号均为3.00
"DataVersion" : "1.00", //PSR固件版本号,每次随着修改点进行版本迭代,如1.01,1.02......2.01,2.02......格式为xx.xx,其中xx范围为1-99,其作用用于区分PSR软件版本。
"DataType":"PSR", //PSR数据类型,取值有CSR、PSR,不显性指定时默认为CSR "ManagementTopology" :
{
... //本组件/部件内的管理拓扑,主要包含Anchor、Bus、Chip、 Connector的层级关系,为Objects功能实体提供准确的链路。
},
"Objects" :
{
... //本组件/部件内需要描述的业务对象,每个业务对象都是一个抽象的功能实体。
}
}0.3 PSR构建策略
PSR构建时一个0502会同时生成一个装备包和一个现网包,装备包需要进行装备测试,需要支持版本内PSR互相升级。现网包为防止伙伴或者客户随便升级PSR修改配置,需要做到不允许不同的PSR互相升级。现网包PSR不支持不同的PSR之间互升,但是需要支持对挂耳CSR进行升级,即需要伪装最初版本挂耳0302的CSR。
构建时新增uid参数,默认值填写需要伪装的uid(包含右挂耳的CSR和版本内所有PSR)。注:现网包不支持PSR互相升级需要CI同步修改构建脚本。
1 PSR版本描述信息配置说明
PSR版本描述信息配置比较简单,每次版本迭代,只需要修改DataVersion。
"FormatVersion" : "3.00", //PSR代次版本号,当前所有PSR代次版本号均为3.00
"DataVersion" : "1.00", //PSR固件版本号,每次随着版本迭代,如1.01,1.02......2.01,2.02......
"DataType":"PSR", //PSR数据类型,取值有CSR、PSR,不显性指定时默认为CSR2 PSR管理拓扑配置说明
ManagementTopology为管理拓扑的关键字,管理拓扑配置的正确性影响管理对象的正常运作。
一个整机的CSR或PSR都是一级一级的加载成功的,当前BMC是直接连接EXU(扩展板),然后扩展板组成了一个完整的功能节点,然后扩展板连接了基础板(BCU)、风扇板(CLU)、硬盘背板(SEU)、板载网卡(NIC)、挂耳-PSR等对象,然后基础板连接了Riser卡,Rsier卡上插有各种PCIE卡。这些连接在CSR中的表现形式就是Connector连接器,框架子系统通过连接器一级一级的进行对象的加载和分发。可以看到,PSR唯一接口为CSR(EXU)的Connector,因此配置PSR管理拓扑时,需要查阅CSR(EXU)为PSR提供的Connector。
下图为扩展板CSR中定义的和PSR对象相连的Connector,可以看到,扩展板当前提供的Buses接口有两个,I2c_8,I2c_2,即扩展板CSR给PSR对象开放了其可以访问I2c_8和I2c_2下所有对象的权限。当前I2c_8为右挂耳板卡IIC通道,I2c_2为扩展板IIC通道,由于扩展板I2c_2通道下面挂载了CPLD对象,因此PSR配置支持和扩展板CPLD进行SMC交互功能。
Buses下面IIC的顺序需要和扩展板CSR其PSR的Connector对象的顺序一致,软件是通过顺序区分其连接关系的,如果PSR涉及和I2c_2下面组件进行数据交互,PSR则需要配置I2c_2。备注:如果PSR不存在和I2c_2下面组件(如CPLD)进行数据交互,可以不配置I2c_2,PSR管理拓扑对象的Buses最大集合为扩展板CSR其PSR的Connector对象的Buses。
"ManagementTopology": {
"Anchor": {
"Buses": [
"I2c_8",
"I2c_2"
]
},
"I2c_2": {
"Chips": [
"Smc_ExpBoardSMC"
]
},
"I2c_8": {
"Chips": [
"Eeprom_1"
]
}
},备注:社区硬件平台当前所有 PSR 的管理拓扑配置均一样,和举例一致,若存在修改场景,需要评审。
3 PSR管理对象配置说明
3.1 通用硬件
3.1.1 UnitConfiguration
整机需要配置高速线缆在位/插错告警,同时需要承接BCU(CPU板)和IEU(Riser卡)之间的连接关系,建立PCIe槽位和CPU资源的对应关系,计算rootBDF,完成PcieAddrInfo对象(bios需要的丝印信息)的属性设置,因此需要配置线缆白名单UnitConfiguration对象。配置线缆白名单前,我们要知道线缆检测的原理,线缆检测总结来看就是:与基础板外接(通过UBCDD/UBC桥接)的每一个外围组件(Riser/背板等)给基础板发数据,告诉基础板“我是谁”。Riser/背板和主板相连的UBC/UBCDD有一根线缆拓扑检测线缆,其会上报Riser/背板组件的UID、线缆检测值作为组件的唯一“ID”。线缆检测详细原理可参考 openUBMC 社区相关文档。
"UnitConfiguration_IEU1": {
"SlotType": "IEU", //单板类型,对应组件名称IEU、SEU、EXU
"SlotNumber": 1, //SLOT号,同一单板类型需要唯一,UnitConfiguration_IEU1配置的所有和主板相连Connector,其基础板端的slot都会重新赋值为SlotNumber,然后传递给riser端,riser端告警/传感器等若引用${slot},该值都为1。该值可以理解成整机上riser唯一代号。
"SlotSilkText": "IEUSlot1", //单板类型+slot+SlotNumber,用于插错告警时,现在的告警内容。如果配置为IEUSlot1,The cable of unit 00000001040302044498(IEUslot1) is absent or the connector is not properly connected.
"Configurations": [
{
"UID": "00000001040302044498",//riser单板的UID
"Index": 1, //CPU号,riser的高速链路和哪个CPU相连,1代表和CPU1相连,2代表和CPU2相连。0代表不区分CPU1和CPU2。配置举例:SrcPortName如果只有ZONE区A/C,配置成1;SrcPortName如果只有ZONE区B/D,配置成2;SrcPortName如果存在不属于上面的场景,配置成0.
"SrcPortName": [
"A2a", //基础板zone区(基础板“纵”“横”2条线一划,形成4个区域,这4个区域成为之ZONE,分别用A、B、C、D代表四个区)+连接器的序号+a/b/c/d(a代表一个macro低八位的低四位、b代表一个macro低八位的高四位、c代表一个macro高八位的低四位、d代表一个macro高八位的高四位)
"A2c"
],
"TargetPortID": [
33, //线缆检测值,为IEU/SEU/EXU上报的线缆检测值,告诉BMC,A2a这个端口上报的线缆检测值为33。
49 //线缆检测值,为IEU/SEU/EXU上报的线缆检测值,告诉BMC,A2c这个端口上报的线缆检测值为49。
],
"Slot": [ //机箱面板riser卡不同CEM槽位在整机规划的槽位号(00000001040302044498单板因为为2*X8,因此有两个CEM,所以有两个slot)
2,
3
],
"Device": [] //要求配置为空。若为空,BMC才会从基础板software.sr中找对应的SerDrs对象。
},
{
"UID": "00000001040302023942",//riser单板的UID
"Index": 1, //CPU号,riser的高速链路和哪个CPU相连,1代表和CPU1相连,2代表和CPU2相连。0代表不区分CPU1和CPU2。配置举例:SrcPortName如果只有ZONE区A/C,配置成1;SrcPortName如果只有ZONE区B/D,配置成2;SrcPortName如果存在不属于上面的场景,配置成0.
"SrcPortName": [ //基础板zone区(基础板“纵”“横”2条线一划,形成4个区域,这4个区域成为之ZONE,分别用A、B、C、D代表四个区)+连接器的序号+a/b/c/d(a代表一个macro低八位的低四位、b代表一个macro低八位的高四位、c代表一个macro高八位的低四位、d代表一个macro高八位的高四位)
"A2a",
"A2c",
"A3a"
],
"TargetPortID": [
33, //线缆检测值,为IEU/SEU/EXU上报的线缆检测值,告诉BMC,A2a这个端口上报的线缆检测值为33。
34, //线缆检测值,为IEU/SEU/EXU上报的线缆检测值,告诉BMC,A2c这个端口上报的线缆检测值为34。
49 //线缆检测值,为IEU/SEU/EXU上报的线缆检测值,告诉BMC,A3a这个端口上报的线缆检测值为49。
],
"Slot": [ //机箱面板riser卡不同CEM槽位在整机规划的槽位号(00000001040302023942单板因为为1*X16+1*X8,因此有两个CEM,所以有两个slot)
2, //
3 //
],
"Device": [] //要求配置为空。若为空,BMC才会从基础板software.sr中找对应的SerDrs对象
},配置举例:如果整机有两种接线配置,其中对于riser1有两种不同的riser卡配置场景,其接线方式见人人懂天池系类第十三期-天池架构之cp_type、拓扑检测方案及实现。
因为是riser类型,因此SlotType填IEU,由于riser1有两种接线方式,因此Configurations需要配置两组:①从上图可知,Configurations下面第一组的UID为00000001040302044498,Index为1(ZoneA区域为1),SrcPortName下面为A2a和A2c,依次对应检测值33和49,riser上面CEM的slot槽位依次对应3和2;②从上图可知,Configurations下面第二组的UID为00000001040302023942,Index为1(ZoneA区域为1),SrcPortName下面为A2a、A2c以及A3a,依次对应检测值33、34和49,riser上面CEM的slot槽位依次对应2和3。最终将上图接线方式翻译成线缆白名单如下所示。
根据白名单将相关信息翻译成UnitConfiguration可配置的结果如下,配置最终结果见上面代码参考。 PCIe槽位和CPU资源建立关系简图举例,UnitConfiguration为承上启下的作用。
部分机型BMC接线和其他机型不一致,需要配置BMC的槽位以同步BDF,见03 EXU/00 EXU配置指导书.md中3.4.10节BMC卡rootBDF自发现。
3.1.2 Dimension
整机高度信息配置,整机高度信息需要配置,给软件提供整机高度数据接口。
"Dimension_1": {
"HeightU": 1 //整机高度,单位U,目前了解到BIOS会获取整机高度。
},3.1.3 BDF Configurations
BDF config用于PCIe建链,槽位信息、portID、BDF关系包含在这个表里。
"BDFConfig_cpu0": {
"Type": "RootBDF",
"SocketId": 0, //对应chip0
"BDFConfigs": [
{
"PortId": 0, //对应port号的起始数据
"ControllerIndex": 0, //对应CORE编号
"Bus": 0, //对应port号的起始bus
"Device": 0 //对应port号的device
},
{
"PortId": 4, //PortId:0-4表示将UBC配置成一个X8。对于NVME硬盘而言,每个UBC对应2个硬盘,需要配置成X4,可按照以下配置
"ControllerIndex": 0,
"Bus": 0,
"Device": 4
},
{
"PortId": 6, //如涉及M.2硬盘,则需要将对应连接的UBC口配置成X2,即一个UBC配置4个portid
"ControllerIndex": 0,
"Bus": 0,
"Device": 6
},
{
"PortId": 8,
"ControllerIndex": 1,
"Bus": 0,
"Device": 20
},
{
"PortId": 10,
"ControllerIndex": 1,
"Bus": 0,
"Device": 22
},
{
"PortId": 12,
"ControllerIndex": 1,
"Bus": 0,
"Device": 16
},
{
"PortId": 14,
"ControllerIndex": 1,
"Bus": 0,
"Device": 18
},
{
"PortId": 16,
"ControllerIndex": 2,
"Bus": 0,
"Device": 8
},
{
"PortId": 18,
"ControllerIndex": 2,
"Bus": 0,
"Device": 10
},
{
"PortId": 20,
"ControllerIndex": 2,
"Bus": 0,
"Device": 12
},
{
"PortId": 22,
"ControllerIndex": 2,
"Bus": 0,
"Device": 14
},
{
"PortId": 24,
"ControllerIndex": 3,
"Bus": 32,
"Device": 0
},
{
"PortId": 26,
"ControllerIndex": 3,
"Bus": 32,
"Device": 0
},
{
"PortId": 28,
"ControllerIndex": 3,
"Bus": 32,
"Device": 0
},
{
"PortId": 30,
"ControllerIndex": 3,
"Bus": 32,
"Device": 0
}
]
},3.2 硬件资源获取及单板器件
3.2.1 SMC
天池架构下,BMC需要和硬件对象进行交互信息,硬件对象通常为CPLD/MCU,BMC通过I2C与硬件对象(CPLD/MCU)进行信息交互,为此需要配置硬件对象(CPLD/MCU)的I2C地址、访问带宽等。
"Smc_ExpBoardSMC": {
"Name": "ExpBoardSMC", //SMC名字名字,PSR上
"Address": 96, //扩展板逻辑CPLD的I2C地址,天池架构中,所有单板SMC地址为0X60(即90)
"AddrWidth": 1, // 地址宽度,单位Byte
"OffsetWidth": 1, // 地址偏移宽度,单位Byte
"WriteTmout": 0, // 写超时,单位ms,当前CSR都这样配置,BMC反馈这个部分无需配置。
"ReadTmout": 0 // 读超时,单位ms,当前CSR都这样配置,BMC反馈这个部分无需配置。
},3.2.2 Scanner
Scanner的功能承载某个单板上CPLD/MCU的某个地址信息,该信息可以用于告警/传感器对象的数据承载。以PSR里Scanner举例,BMC软件如果需要获取背板低速线在位信号,BMC软件不清楚这个低速信号存放在CPLD/MCU的哪个地址以及哪个比特位,因此需要配置Scanner告诉BMC这个信息存放在哪个位置。
"Scanner_HddBPPresent": { //前置背板在位告警,历史原因,如果涉及前置背板在位告警需要配置。
"Chip": "#/Smc_ExpBoardSMC", //SMC对象,告诉BMC软件这个Scanner需要从哪个SMC中获取数据
"Offset": 134237440, //Smc命令字的Opcode+Param
"Size": 1, //获取数据的长度,单位字节。
"Mask": 1, //获取数据的掩码
"Type": 0, //数据获取的方式,0:位操作,1:块操作
"Period": 8000, //BMC软件获取数据的周期,数据获取周期有相关规范,非规范内的需要找BMC评审
"Debounce": "#/ContBin_HddBPPresent",//数据防抖,获取的数据可能存在抖动,需要对数据进行预处理
"Value": 1 //Scanner的默认值
},【注意事项】
- Scanner扫描周期配置原则,必须按照如下分类进行配置,如果新增的Scanner不在已有分类,则需要规范评审刷新分类才能添加。 (1)、BCU和EXU的PowerGood告警,周期为100ms (2)、影响业务类的离散电压,周期为400ms (3)、影响业务类的时钟告警,周期为400ms (4)、影响业务类的CPU故障告警,周期为400ms (5)、业务关键状态:系统复位,上电超时,异常掉电,ThermTrip,周期为400ms (6)、故障诊断的故障检测,周期为1s (7)、硬盘类状态扫描,周期为5s (8)、不影响业务的硬件状态,周期为5s (9)、热插拔部件在位状态,周期为2s (10)、非热插拔部件在位扫描,周期为8s (11)、门限类温度扫描,周期为1s (12)、门限类电压扫描,周期为3s (13)、纽扣电池扫描,周期为10s (14)、风扇转速扫描,周期为1s (15)、RTC时间同步,周期为6s (16)、按钮交互类,比如UID按钮,周期为1s (17)、风扇、电源总功耗扫描,周期为1s (18)、光模块温度,周期为10s,连续12次失败认为异常 (19)、面板电源按钮,周期为200ms 二值持续一致滤波说明
ContBin_HddBPPresent": {
"NumH": 4, //高电平防抖次数,连续4次为1才为1
"NumL": 4, //低电平防抖次数,连续4次为0才为0
"DefaultValue": 1 //默认值
},- 配置Scanner时需要考虑Scanner是否需要一直使能,不需要的话需要在ScanEnabled属性配置使能条件,例如VCC上电才需要使能,需要在ScanEnabled同步单板的PG状态。
BMC推荐的CSR硬件监控防抖机制详见:官方链接
3.2.3 EEPROM
天池架构规范规定每个组件上必须存在一个在I2C总线上地址为0xAE的存储器件,当前均为Eeprom器件,用于存储硬件自描述信息,包含头部、电子标签、组件自描述信息(CSR/PSR)以及扩展信息等,该规范当前由BMC维护,见《天池组件eeprom头定义》文档。天池规范定义了SR的存储载体的I2C地址固定为0xAE。在PSR中,我们需要其相关的器件信息如下:
"Eeprom_1": {
"OffsetWidth": 2, // 偏移宽度,单位byte
"AddrWidth": 1, // 偏移宽度,单位byte
"Address": 174, // EEPROM的I2C地址,0xAE即10进制的174
"WriteTmout": 100, // 写超时,单位ms
"ReadTmout": 100, // 写超时,单位ms
"RwBlockSize": 32, // 分页读写Eeprom的数据大小,单位Byte,U16类型,最大允许取值1024,默认值32
"WriteInterval": 20, // 分页写延时间隔,单位ms,最大允许取值500
"HealthStatus": 0 // 器件健康状态,默认配置为0,由软件更新
},3.2.4 Fru
天池架构下,单板的电子标签也存放在CSR/psr所在的Eeprom中,配置对应的Fru对象来进行管理,FRU即现场可替换单元(field replacement unit ),在CSR/PSR中的FRU对象用于描述产品的身份信息,如制造厂商、产品型号、版本、资产标签等。
"Fru_PSR": {
"PcbId": 1, //PCBID,当PcbId为0/1时,显示.A版本,当PcbId为2时显示.B版本,以此类推。
"PcbVersion": ".A", //PCB版本,软件会自动刷新,当PcbId为0/1时,显示.A版本,当PcbId为2时显示.B版本,以此类推。
"FruId": 0, //PSR承载在挂耳板上,BMC每次重启,挂耳板FruId默认配置为0,CSR组件配置FruId值在1-63范围内,每次BMC重启会按照自发现顺序重新给每个组件分配FruId,如果配置64-255则不会进行FruId分配。
"FruName": "BMC", //PSR默认写BMC
"PowerState": 1, //Fru关联的热插拔状态,如果不支持可以直接配成1,支持热插拔则需要关联对应的ChassisPayload的PowerState
"Health": 0, //软件未使用,历史问题所有PSR一直存在这个属性,放在这里是告知大家软件当前其实未使用
"EepStatus": 1, //软件未使用,历史问题所有PSR一直存在这个属性,放在这里是告知大家软件当前其实未使用
"Type": 0, //FRU类型 BCU:36 EXU:50 IEU:195 MotherBoard:0 BMCcard:26,PSR当前按照BMCcard配置
"FruDataId": "#/FruData_Fru0" //管理FruData对象,FruData对象承载在software.sr里。
},| 类名 | 数据类型 |
|---|---|
| FruId | 单板的FruIdfruid配置为1-63会根据自发现顺序自动分配fruid,默认可以配为1,fruid为0保留给挂耳,配置64-255不会进行fruid分配 |
| FruDataId | 关联FruData对象 |
| Type | FRU类型 BCU:36 EXU:50 IEU:195 MotherBoard:0 BMCcard:26 |
| FruName | Fru名称 |
| BoardId | 单板ID, 表示单板的类型, 加载xml时会根据boardid加载, 所以该值可以根据xml的名称来确定该值. |
| EepStatus | EEPROM状态, 当此属性关联到Accessor时, Frudata模块会启动任务进行EEPROM的监控,不管理可配置为1 |
| PcbId | PcbId, 需要关联到硬件, 从硬件读取Id. |
| PcbVersion | PCB版本, 根据PcbId的值进行计算得出, PcbId为0/1时, 显示.A , 为2时显示.B, 依次类推 |
备注:FruData配置在software.sr里。
3.3 组件管理(BMC软件维护)
3.3.1 告警管理
Event也叫精细化告警,主要包括了sensor和BMC其他精细化告警,硬件sr里主要包括以下内容:
1、前置硬盘背板不在位告警:硬盘背板不在位告警(从扩展板获取单板组件在位信息)。
2、整机输入功率过高告警:整机输入功率如果超过软件设定值,触发告警。
3、功率封顶触发告警:功率封顶操作如果成功触发,触发告警。
4、功率封顶失败告警:功率封顶操作如果失败,触发告警。
5、电源数量缺失告警:上电时检测电源数量,若在运行过程中发现数量少于上电时的电源数量,触发告警。
6、线缆不在位告警。
精细告警中的告警门限值需要与软硬件接口文档对应,且完成评审归档。
1. 属性说明
(不配置则使用数据类型的默认值,所以按需配置即可)
| 属性 | 描述 |
|---|---|
| 对象名Event_xxx | Event是固定值,看做是Class,所有Event类都会分发到事件模块处理 xxx是名称,无功能意义,单个文件不重复即可,完整名称自发现会根据SR文件拼接,比如拼接成Event_xxx_0101 |
| EventKeyId | (必配)事件标识,用于匹配事件静态配置,例如告警描述等信息, 要在BMC内部定义,才能产生告警,见第三小节的列表 |
| Reading | (必配)告警读数,普通的事件比如温度可以直接拿来当做读数,其他类型的比如证书过期,可以是0和1来代替 最终是结合运算符、门限判断是否符合告警条件,所以根据业务场景配置即可 |
| Condition | (必配)告警门限值 |
| OperatorId | 判断符号 1:小于 2:小于等于 3:大于 4:大于等于 5:等于 6:不等于 7:上升沿0->1产生,1->0恢复 8:下降沿1->0产生,0->1恢复 注:上升沿下降沿时,值只有0/1/255,其中255表示无效值不会处理,且不要出现小数 |
| Hysteresis | 迟滞量 在恢复告警时使用,产生告警时不会使用,迟滞量支持负数,所以根据正负数表征正向/负向迟滞量 |
| Enabled | 事件使能状态,或者称为屏蔽状态,被屏蔽后不再会进行读值检测 |
| DescArgx/SuggArgx | (选配) 事件的描述/建议参数,用于格式化参数,即替换描述模板中的%1、%2等占位符,如DescArg1替换描述中的%1 仅支持字符串格式,最多10个 注:如果对于浮点数期望显示为3位小数,则需要通过SR表达式format进行转换 |
| Component | 关联的Component对象,正常情况下Component部件需要与事件码高位匹配,用于显示告警主体 例如:查询环境有无对应的Component Type等于事件码高位例如0x02xxxxxx则需要查找Type为2的部件 |
| AdditionalInfo | (选配)事件的附加信息,即第X个动态参数,也可以是‘1,2’指向多个,用于FD上报时区分不同事件 比如完全相同的告警仅槽位不同,一般用槽位做区分,新增的告警需要特别注意是否需要配置 |
| LedFaultCode | (选配) Led错误码,可以是固定值也可以是动态值x$ (取Component中的Instance填充$部分) |
| InvalidReadingIgnore | (选配)是否忽略无效值,1:开启 0 : 关闭,开启后读值如果等于InvalidReading则忽略 |
| InvalidReading | (选配) 需要忽略的无效值 |
2. 告警产生逻辑
根据OperatorId的判断方式,将Reading的值和Condition做比较,判断为真产生告警。即:
是否产生: Reading OperatorId Condition
是否恢复: (Reading + Hysteresis) OperatorId Condition
例如OperatorId为5时,则会判断 Reading == Contion 是否成立
3. EventKeyId列表
社区版本定义迁移到vpd中,详细参考社区告警文档
4. 业务简图
1-5告警配置举例(当前告警拆分成software.sr和硬件sr,这里只描述硬件sr部分)
"Event_HDDBpPresenceMntr": { //前置硬盘背板不在位告警,按照实际情况是否有背板进行配置
"EventKeyId": "Chassis.ChassisFrontDiskBackplaneNotPresent", // 事件码,对应BMC不同的告警码
"Condition": 0 //告警比较对象
},
"Event_SystemPowerHigh": { //整机输入功率过高告警
"EventKeyId": "System.SystemPowerHigh", // 事件码,对应BMC不同的告警码
"Condition": "<=/EnergyMetric_1.HighPowerThresholdWatts", //告警比较对象
},
"Event_SystemPowerCapTriggered": { //功率封顶触发告警
"EventKeyId": "System.SystemPowerCapTriggered", //事件码,对应BMC不同的告警码
"Condition": 1, //告警比较对象
},
"Event_SystemPowerCapFailure": { //功率封顶失败告警
"EventKeyId": "System.SystemPowerCapFailure", //事件码,对应BMC不同的告警码
"Condition": 1, //告警比较对象
},
"Event_PSURedundancyLost": { //电源数量缺失告警
"EventKeyId": "PSU.PSURedundancyLost", //事件码,对应BMC不同的告警码
"Condition": 1, //告警比较对象
},线缆不在位告警历史版本存在告警漏配问题,这里要注意每个配置都要有对应的告警。例如配置一个UnitConfiguration_IEU1_BCU2就要有一个对应的Event_IEU1_BCU2_UBNotPresent。
线缆不在位告警举例,线缆不在位告警事件码固定位Cable.UBNotPresent,Reading固定调用均为对应UnitConfiguration_xx.Port1Status,Condition配置为4(因为Port1Status为4代表组件不在位),OperatorId配置成5(即当Reading和Port1Status相等时,产生告警)。
"Event_IEU1_UBNotPresent": {
"EventKeyId": "Cable.UBNotPresent", //事件码,对应BMC不同告警码
"Reading": "<=/UnitConfiguration_IEU1.Port1Status", //固定写法,引用对应线缆白名单对象,格式为UnitConfiguration_xx.Port1Status.Port1Status值由BMC软件进行刷新
"Condition": 4,
"@Default": { //使用了同步语法的属性的默认值,为Reading属性的默认值(Reading使用了<=)。<=表示同步语法,#/是保留关键符号,。
"Reading": 255
},
"ComponentId": 40, //默认配置
"OperatorId": 5, //告警产生条件,5代表当Reading值等Condition值时产生告警
"Enabled": true, //事件使能状态,或者称为屏蔽状态
"DescArg1": "#/UnitConfiguration_IEU1.Port1LinkInfo",//告警显示内容,线缆不在位告警固定这样配置
"Component": "#/Component_Cable"
},Port1Status属性数值说明,该值为BMC刷新,硬件调用,如下表所示,当前PSR均和值“4”对比,作为线缆不在位告警触发。
| Port1Status数值 | 含义解释 |
|---|---|
| 0 | 初始状态,状态去重之后设置 |
| 1 | 匹配成功 |
| 2 | 线缆连接错误 |
| 3 | 组件不支持,线缆白名单中没有配置该组件 |
| 4 | 组件不在位/存在 |
| 5 | 组件连接不完整(部分线缆未插或连接器连接不完整) |
| 255 | 状态255未Event忽略值,Event不会进行告警产生/回复 |
备注:Component_Cable对象配置在software.sr里。
3.3.2 传感器管理
门限传感器
对于PSR而言,PSR只有一个整机输入功率传感器,其中硬件SR里面值配置如下。
"ThresholdSensor_SysTotalPower": {
"AssertMask": 0, //传感器事件产生掩码,决定是否能产生事件,根据传感器实际配置的"UpperNoncritical"等上下限按需配置
"DeassertMask": 0, //传感器事件恢复掩码,决定是否能恢复事件,根据传感器实际配置的门限按需配置
"ReadingMask": 0, //传感器读值掩码,决定是否能对外显示门限,根据软硬件接口文档中的“UpperNoncritical”等上下门限按需配置
"Linearization": 0, //传感器线性计算方程
"M": 11//传感器M计算表达式低8bit,决定传感器原始值转换到读值的转换公式参数
},备注:Entity对象配置在配置在software.sr里。
注意:配置门限传感器时需要考虑传感器使能状态是否受到实体在位和上下电的影响,Capabilities属性(该属性一般配置在soft.sr中)需要按照规范配置
①若传感器使能状态不受实体在位及上下电影响(一般对应关联的实体的Prsence和PowerState配死为1),则配置为104
②若传感器使能状态受实体在位及上下电影响,则配置为232
门限传感器SEL检测流程:
离散传感器
对于PSR而言,离散传感器有电源容量状态传感器,配置如下:
"DiscreteSensor_PwrCapStatus": {
"OwnerId": 32, //关联对应实体的Id属性,BMC software·sr配置
"OwnerLun": 0, //BMC software·sr配置
"EntityId": "<=/Entity_MainBoard.Id",
"EntityInstance": "<=/Entity_MainBoard.Instance", //BMC software·sr配置
"Initialization": 99, //传感器初始化选项,门限传感器 - 0x63
"Capabilities": 192, //传感器能力,具体含义见IPMI标准协议规范43.1章节;
"SensorType": 18, //传感器类型,BMC software·sr配置
"ReadingType": 3, //传感器读值类型,BMC software·sr配置ThresholdSensor则配置为0x01
"SensorName": "PwrCap Status", //传感器名称,BMC software·sr配置
"AssertMask": 3, //传感器事件产生掩码,硬件配置
"DeassertMask": 3, //传感器事件恢复掩码,硬件配置
"DiscreteMask": 3, //传感器离散值掩码,硬件配置
"Unit": 192, //传感器单位配置,,离散传感器-0xc0,BMC software·sr配置
"BaseUnit": 0, //离散传感器无单位,配置为0,BMC software·sr配置
"ModifierUnit": 0,
"RecordSharing": 1, //离散传感器配置类型,普通离散为0,数字互斥离散为1,BMC software·sr配置
"PositiveHysteresis": 0, //BMC software·sr配置
"NegativeHysteresis": 0, //BMC software·sr配置
"Reading": 0, //BMC software·sr配置
"SensorNumber": 255 //无传感器编号定制需求,则不配置或配死为255,由sensor模块分配
},注意:配置离散传感器时需要考虑传感器使能状态是否受到实体在位和上下电的影响,Capabilities属性(该属性一般配置在soft.sr中)需要按照规范配置
①若传感器使能状态不受实体在位及上下电影响(一般对应关联的实体的Prsence和PowerState配死为1),则配置为64
②若传感器使能状态受实体在位及上下电影响,则配置为192
离散传感器SEL检测流程:
3.3.3 升级管理
SRUpgrade为BMC针对EEPROM定义的升级管理对象,要实现升级PSR的功能,需要配置该对象。
"SRUpgrade_1": {
"UID": "000000010402315GYW", //整机UID组成:厂商ID+产品组件类型+挂耳模块部件编码组成。其中:示例厂商ID为00000001,PSR承载在右挂耳上,右挂耳组件类型为04,挂耳模块部件条码由项目版本提供。
"Type": "PSR", //升级对象类似,描述升级对象是PSR还是CSR,PSR配置为PSR
"Version": "${DataVersion}", //版本号,默认采用引用语法,${DataVersion}
"StorageChip": "#/Eeprom_1", //升级对象,需要绑定PSR升级的EEPROM对象
"SoftwareId": "XXX-YYYYY" //编码信息,配置格式按 XXX-单板名称,其中单板名称在PDM上查询挂耳模块部件。
},单板名称查询举例:PDM上搜索02315GYW编码,下图红框处就是单板名称。
厂商ID说明(参考 openUBMC 社区《组件ID分类和ID管理》文档),后续如果涉及其他厂商ID配置,可与社区维护者对齐。
| 产商ID(ProductVendorID) | 厂家 |
|---|---|
| 0x00000001 | Huawei |
| 0x00000002 | 同方 |
| 0x00000003 | 宝德 |
| 0x00000004 | 长江计算 |
| 0x00000005 | H3C |
| 0x00000006 | 神州数码 |
| 0x00000007 | 百信 |
| 0x00000008 | 华鲲 |
3.3.4 对外数据接口
3.3.4.1 Product
Product对象承载服务器整机的标准化配置信息,包含以下核心属性:整机名称、整机示意图、产品整机唯一产品标识符(ProductUniqueID)及厂商ID(ProductVendorID),其核心功能为向BMC提供整机数据接口。特别说明:通过VendorID与ProductID的二进制位拼接算法,可生成具有唯一性的设备识别码ProductUID(格式:ProductVendorID<< 16 | ProductUniqueID)。
"Product_1": {
"ProductName": "S920X20", //整机名称——用于BMC界面显示,配置完BMC登录后,界面左上角会显示该名称。
"ProductAlias": "", //产品别名——软件/redfish/v1/SystemOverview、/UI/Rest/Overview相关接口有调用该数据,PSR需要配置一个空的载体给软件,BMC会自动刷新。——要求软件自动带出。
"ProductPicture": "img_01", //BMC界面整机显示的图片——BMC软件会针对整机显示的图片进行编号,如img_01,img_02,这里配置整机需要显示正确的图片编号。
"ProductUniqueID": "0x030ABF00", //产品唯一ID——一个整机产品的编码。
"ProductVendorID": "0x00000001" //厂商ID,整机ID的前八位即厂商ID,如示例厂商ID:0x00000001
},以920F的PSR配置举例:该对象的配置需要参考 openUBMC 社区 ProductUID 分配相关文档(含天池整机 ProductUID 分配表)。ProductUID低四个byte组成产品ID,ProductUID高四个byte为厂商ID。 厂商ID说明参考3.3.3 升级管理
3.3.4.2 Contact
Contact对象为整机对外联系方式等信息的集合,如网址、邮箱以及电话等信息,PSR只需要配置一个载体给软件,装备定制化环节会重新刷新数据,当前PSR配置均默认安装下面格式模版填写即可。
"Contact": {
"OfficalWeb": "", //技术支持网站的网址,装备定制化环节刷新数据。
"SupportWeb": "", //联系邮箱,装备定制化环节刷新数据。
"Email": "", //联系电话,装备定制化环节刷新数据。
"Phone": "", //版权,装备定制化环节刷新数据。
"Copyright": "", //默认版权,装备定制化环节刷新数据。
"DefaultCopyright": "", //默认版权,装备定制化环节刷新数据。
"QRCodeSupported": false //web网页是否支持显示二维码,装备定制化环节刷新数据。
}3.3.4.3 ChassisBMC
ChassisBMC是在redfish接口展示用的,用于描述bmc的信息的,目前ChassisBMC这个对象的所有属性BMC要求固定按照下面模版进行配置。
"ChassisBMC_1": {
"NodeId": "chassisBMC", //BMC要求固定写成chassisBMC
"Description": "BMC", //BMC要求固定写成BMC,redfish接口暂未使用
"Number": 0, //BMC要求固定写成0,redfish接口暂未使用
"DeviceName": "BMC", //BMC要求固定写成BMC
"Type": "BMC", //BMC要求固定写成BMC,redfish接口暂未使用
"Position": "chassis", //BMC要求固定写成chassis,BMC插卡在整机的位置
"Manufacturer": "<=/FruData_Fru0.BoardManufacturer", //FRU制造厂商信息
"PartNumber": "<=/FruData_Fru0.BoardPartNumber", //FRU单板编码信息
"PcbVersion": "<=/Fru_PSR.PcbVersion", //PCB版本
"Name": "<=/FruData_Fru0.BoardProductName", //FRU整机名称信息
"BoardID": 65535, //BoardID
"FruID": "<=/FruData_Fru0.FruId", //Fruid信息
"BoardType": "BMC", //BMC要求固定写成BMC
"UID": "000000010402315GYW" //整机UID组成:厂商ID+产品组件类型+挂耳模块部件编码组成。其中:示例厂商ID为00000001,PSR承载在右挂耳上,右挂耳组件类型为04,挂耳模块部件条码由项目版本提供。
}3.3.5 能效管理
1.Coolling模块说明:CoolingPolicy为线性调试策略,CoolingRequirement 为某个温度点调试策略(可以理解成PID调速),CoolingConfig 承载了Cooling对象初始化配置及变量调用 ,CoolingFan当前配置在风扇板中,所有Coolling模块最终由CoolingArea承载,其关系见上文各对象说明。
CoolingArea用来关联温度点(RequirementIdx)、参与调速的风扇(FanIndxGroup)和调速策略(PolicyIdxGroup),CoolingArea与CoolingRequirement应该一一对应;CoolingArea只能配置到PSR中(区分单电源和双电源);CoolingRequirement一般跟随单板所在的SR配置
2.MPCModel对象,今后不需要配置(5.7.0及以上版本BMC不需要配置),但老版本BMC需要配置兼容。
3.3.5.1 CoolingConfig
调速配置,一个PSR一般只需要配置一个对象CoolingConfig ,主要用于承载cooling模块的全局配置,该对象主要包含功能:①智能调速模式的使能及初始化模式配置;②风扇手动调速运行的范围约束;③提供一些状态信息,如SSD/HHD温度,其他cooling对象进行调速策略配置需要调用这个状态信息。
| Interface/Private | 属性/方法 | 描述 | 是否由CSR配置 |
|---|---|---|---|
| bmc.kepler.Systems.CoolingConfig | SmartCoolingState | 智能调速使能状态 | 是 |
| bmc.kepler.Systems.CoolingConfig | SmartCoolingMode | 智能调速模式 | 是 |
| bmc.kepler.Systems.CoolingConfig | Medium | 散热介质(风/液/风液混合) | 否 |
| bmc.kepler.Systems.CoolingConfig | CtrlMode | 冷却单元的控制模式(自动/手动/混合) | 否 |
| bmc.kepler.Systems.CoolingConfig | TimeOut | 手动模式下的风扇超时时间 | 否 |
| bmc.kepler.Systems.CoolingConfig | ManualLevel | 手动模式下的风扇转速级别 | 否 |
| bmc.kepler.Systems.CoolingConfig | LevelPercentRange | 手动设置转速级别允许范围 | 是 |
| bmc.kepler.Systems.CoolingConfig | SensorLocationSupported | 是否支持温度海洋界面显示 | 是 |
| bmc.kepler.Systems.CoolingConfig | MinAllowedFanSpeedPercent | 失联状态场景风扇转速级别 | 是 |
| bmc.kepler.Systems.CoolingConfig | MinAllowedFanSpeedEnabled | MinAllowedFanSpeedPercent 使能状态 | 是 |
| bmc.kepler.Systems.CoolingConfig | MixedModeSupported | 是否支持混合模式场景,true:支持混合模式,false:不支持混合模式 | 是 |
| bmc.kepler.Systems.DiskCoolingConfig | DiskRowTemperatureAvailable | 背板上硬盘温度是否能正常获取 | 是 |
| bmc.kepler.Systems.DiskCoolingConfig | SysHDDsMaxTemperature | HDD硬盘最大温度, 单位:摄氏度 | 是 |
| bmc.kepler.Systems.DiskCoolingConfig | SysSSDsMaxTemperature | SSD硬盘最大温度(仅SAS/SATA), 单位:摄氏度 | 是 |
| bmc.kepler.Systems.DiskCoolingConfig | SysM2sMaxTemperature | M.2硬盘最大温度, 单位:摄氏度 | 是 |
| bmc.kepler.Systems.DiskCoolingConfig | SysAllSSDsMaxTemperature | 所有SDD介质硬盘的最大温度, 单位:摄氏度, 默认温度异常值为32768 | 是 |
| Private | Id | 对象ID | 否 |
| Private | FanBoardNum | 风扇板数量,多风扇板场景,当加载风扇板数量与配置相同时,启动自动调速 | 是 |
| Private | OriginalSmartCoolingMode | 智能调速模式CSR原始值 | 否 |
| Private | InitLevelInStartup | BMC启动初始转速 | 是 |
"CoolingConfig_1": //主要用于承载cooing模块的全局配置,该对象下面的大部分属性都是给给其他cooling组件调用的。
{
"SmartCoolingState": "Enabled", // 是否使能智能调速模式,智能调速模式主要有Custom(自定义模式)、HighPerformance(高性能模式)、LowNoise(低噪音模式)、EnergySaving(节能模式)、LiquidCooling(液冷模式)五种。Enabled:使能;Disabled:未使能。
"SmartCoolingMode": "EnergySaving", //初始状态的调速模式,智能调速模式主要有Custom(自定义模式)、HighPerformance(高性能模式)、LowNoise(低噪音模式)、EnergySaving(节能模式)、LiquidCooling(液冷模式)五种,启动后BMC软件会刷新这个状态。软件当前都是基于节能模式启动的。
"LevelPercentRange": [ //手动调速模式范围,手动模式下,允许调节风扇转速的百分比范围
10,
100
],
"InitLevelInStartup": 100, //初始转速,BMC软件调速配置生效前风扇默认的转速(上电过程中下发的转速)
"DiskRowTemperatureAvailable": false, //一个标志位,可以用于判断当前是否可以获取硬盘温度,默认配置为false,软件会刷新。常规用于环温调速生效判断。
"SysHDDsMaxTemperature": 0, //环境中HDD硬盘的最大温度,单位:摄氏度,BMC软件会获取HDD硬盘最大温度然后赋值给这个属性。
"SysSSDsMaxTemperature": 0, //环境中SDD硬盘的最大温度,单位:摄氏度,BMC软件会获取HDD硬盘最大温度然后赋值给这个属性。
"SensorLocationSupported": true //功能使能,是否支持温度海洋功能,true:支持,false:不支持。
},配置举例:风扇手动调速区间范围见 CoolingConfig 对象 LevelPercentRange 属性说明,在CoolingConfig对象下LevelPercentRange属性中需要将转速范围配置成10%—100%,因此LevelPercentRange配置为10,100。
3.3.5.2 CoolingPolicy
线性调速功能配置,一个CoolingPolicy对象就是一条调速曲线,如一台服务器整机中有进风口部分(一般是前置背板)、有网卡、有硬盘等,如果其存在线性调速功能需求(以网卡举例:如果不同温度区间有对应不同风扇转速的要求),这个时候就需要配置一个CoolingPolicy对象。 备注:哪些对象存在线性调试功能的需求,热设计传递的《XX整机系统风扇调速策略》里面有承载。——《XX整机系统风扇调速策略》
| Interface/Private | 属性/方法 | 描述 | 是否由CSR配置 |
|---|---|---|---|
| bmc.kepler.Systems.CoolingPolicy | PolicyIdx | 线性调速策略id | 是 |
| bmc.kepler.Systems.CoolingPolicy | PolicyType | Policy类型,用于标识特定Policy对象 | 是 |
| bmc.kepler.Systems.CoolingPolicy | IsValid | 策略是否生效,1生效,0不生效 | 是 |
| bmc.kepler.Systems.CoolingPolicy | ExpCondVal | 预期生效条件 | 是 |
| bmc.kepler.Systems.CoolingPolicy | ActualCondVal | 实际生效条件 | 是 |
| bmc.kepler.Systems.CoolingPolicy | CustomSupported | 是否支持自定义调速 | 是 |
| bmc.kepler.Systems.CoolingPolicy | FanSpeedRangePercents | 自定义调速曲线风扇速度范围 | 是 |
| bmc.kepler.Systems.CoolingPolicy | Hysteresis | 迟滞量 | 是 |
| bmc.kepler.Systems.CoolingPolicy | TemperatureRangeLow | 线性调速策略温度区间低门限 | 是 |
| bmc.kepler.Systems.CoolingPolicy | TemperatureRangeHigh | 线性调速策略温度区间高门限 | 是 |
| bmc.kepler.Systems.CoolingPolicy | SpeedRangeLow | 线性调速策略转速区间低门限 | 是 |
| bmc.kepler.Systems.CoolingPolicy | SpeedRangeHigh | 线性调速策略转速区间高门限 | 是 |
| Private | FanType | 风扇类型列表,环境风扇类型为列表之一时,风扇条件生效 | 是 |
| Private | DiskTempUnavailableToValid | 调速策略生效条件,硬盘温度失效时,若期望该调速策略生效,配置为1,否则配置为0 | 是 |
| Private | HDDBackPlaneName | 前置硬盘背板名,调速策略生效条件,当配置的前置硬盘背板名与整机实际加载前置硬盘背板匹配时,调速策略生效 | 是 |
| Private | HDDRearBackPlaneName | 后置硬盘背板名,调速策略生效条件,当配置的后置硬盘背板名与整机实际加载后置硬盘背板匹配时,调速策略生效 | 是 |
| Private | PCIeCardName | PCIe卡名,调速策略生效条件,当配置的PCIe卡名与整机实际加载PCIe卡匹配时,调速策略生效 | 是 |
| Private | CoolingMedium | 散热介质 | 是 |
| Private | OriginTemperatureRangeLow | 线性调速策略温度区间低门限CSR原始值 | 否 |
| Private | OriginTemperatureRangeHigh | 线性调速策略温度区间高门限CSR原始值 | 否 |
| Private | OriginSpeedRangeLow | 线性调速策略转速区间低门限CSR原始值 | 否 |
| Private | OriginSpeedRangeHigh | 线性调速策略转速区间高门限CSR原始值 | 否 |
"CoolingPolicy_1_6": {
"PolicyIdx": 6, //ID号,整机角度必需唯一,CoolingArea对象通过这个ID来绑定CoolingPolicy,为了保证整机ID不冲突,BMC已在整理规范,后续会发布到社区,作为调试ID的配置约束。
"ExpCondVal": "EnergySaving",//调速策略预期生效模式,模式有Custom(自定义模式)、HighPerformance(高性能模式)、LowNoise(低噪音模式)、EnergySaving(节能模式)、LiquidCooling(液冷模式)。热设计传递的《XX整机系统风扇调速策略》里面有承载。
"ActualCondVal": "<=/CoolingConfig_1.SmartCoolingMode",//当这个值等于ExpCondVal时,该调速策略生效。从CoolingConfig中获取当前智能调速的模式状态,当前该模式状态等于ExpCondVal属性配置的模式时,该CoolingPolicy_1_20线性调试模式才生效。所有CoolingPolicy对象都配置为这个。CoolingConfig_1.SmartCoolingMode。
"Hysteresis": 1,//调速迟滞量。热设计传递的《XX整机系统风扇调速策略》里面有承载。
"TemperatureRangeLow": [-127,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,45,47], //温度范围下门限
"TemperatureRangeHigh": [20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,45,47,127], //温度范围上门限
"SpeedRangeLow": [20,20,21,22,22,23,24,25,26,26,27,28,29,30,30,31,32,33,34,35,37,38,40,42,43,46,52], //风扇转速百分比下门限
"SpeedRangeHigh": [20,20,21,22,22,23,24,25,26,26,27,28,29,30,30,31,32,33,34,35,37,38,40,42,43,46,52], //风扇转速百分比上门限
"FanType": ["02315BQL 4056++"], //02315BQL为风扇部件物料编码,4056++为风扇的一般名称,40表示风扇的直径为40,56代表风扇的深度为80。该值需要和风扇板CSR中配置的FanType对象中Name属性一样,如果获取整机所有FanType对象的Name属性,没有找到02315BQL 4056++,则该CoolingPolicy_1_20线性调试模式直接失效。
"HDDBackPlaneName": ["IT31NHBB"] //硬盘背板名称,需要和背板CSR中配置的HddBackplane对象中Name属性一样,如果获取整机所有HddBackplane对象的Name属性,没有找到IT31NHBB,则该CoolingPolicy_1_20线性调试模式直接失效。--IT31NHBB,HDDBackPlaneName添加多个背板——确定风冷整机PSR咋配置的
},配置举例:其要求硬盘背板在位,即HDDBackPlaneName需要配置为IT31NHBB,Smartcooling调试模式要求默认模式,模式模式即要求所有模式都需要配置线性调速模式,这里以配置节能模式举例,即ExpCondVal为EnergySaving,温度范围及对应的风扇转速百分比,调速迟滞量为1,即Hysteresis为1。 风扇板CSR为05024ARG,找到FanType,风扇FanType的Name为02315BQL 4056++,即FanType为02315BQL 4056++。
3.3.5.3 CoolingRequirement
CoolingRequirement用于描述整机调速中的目标调速策略,策略信息由CSR配置,如温度点读值、目标温度、温度点状态、温度点失效调速、目标调速生效条件等。软件通过加载CoolingRequirement CSR,对目标调速策略进行管理,输出PWM至散热器件,实现整机散热管理。
| Interface/Private | 属性/方法 | 描述 | 是否由CSR配置 |
|---|---|---|---|
| bmc.kepler.Systems.CoolingRequirement | ActiveInStandby | Standby下调速是否生效,true:生效;false:不生效 | 是 |
| bmc.kepler.Systems.CoolingRequirement | CustomSupported | 是否支持自定义目标温度值,true:支持,false:不支持 | 是 |
| bmc.kepler.Systems.CoolingRequirement | CustomTargetTemperatureCelsius | 用户自定义温度值,255为默认无效值, 当CustomSupported为True时,自定义调速模式下使用改属性作为调速点的目标调速值 | 是 |
| bmc.kepler.Systems.CoolingRequirement | FailedValue | 温度状态异常后的调速转速,不配代表该目标调速策略无异常调速;如果配置了值,温度点读取失败的时候,该策略输出PWM为该属性配置值 | 是 |
| bmc.kepler.Systems.CoolingRequirement | MaxAllowedTemperatureCelsius | 满转转速的温度值,当该策略管理温度值达到该属性配置值时,该策略输出PWM为100 | 是 |
| bmc.kepler.Systems.CoolingRequirement | MonitoringStatus | 温度点传感器状态,温度点状态 0:正常 1:异常,该属性非0时,调速策略使用FailedValue输出PWM | 是 |
| bmc.kepler.Systems.CoolingRequirement | MonitoringValue | 调速策略对应的温度点温度值 | 是 |
| bmc.kepler.Systems.CoolingRequirement | RequirementId | 目标调速策略Id,Id必须全局唯一,当前Id支持有效16位,前8位baseid,后8位Slot | 是 |
| bmc.kepler.Systems.CoolingRequirement | SensorName | 调速策略对应的温度点传感器名 | 是 |
| bmc.kepler.Systems.CoolingRequirement | SmartCoolingTargetTemperatureCelsius | 智能调速模式策略,即EnergySaving/HighPerformance/LowNoise 三种模式下的目标温度值 | 是 |
| bmc.kepler.Systems.CoolingRequirement | TargetTemperatureCelsius | 目标温度值,用于PID目标调速计算 | 是 |
| bmc.kepler.Systems.CoolingRequirement | TargetTemperatureRangeCelsius | 自定义模式温度允许范围,用于自定义目标值时的合法性判断,仅支持自定义模式策略配置生效 | 是 |
| bmc.kepler.Systems.CoolingRequirement | TemperatureType | 目标调速温度点类型 | 是 |
| Private | BackupRequirementIdx | 备用目标调速策略ID,当温度点异常时使用该属性对应目标调速策略温度值计算PWM | 是 |
| Private | BaseId | 调速策略基础ID,RequirementId前8位 | 否 |
| Private | CoolingMedium | 调速策略对应散热介质 | 是 |
| Private | Enabled | 调速策略生效条件,true有效,false无效,可通过配置该属性自定义该调速策略的生效条件 | 是 |
| Private | IsBackupRequirement | 是否作为备份温度点 | 是 |
| Private | IsValid | 调速策略是否生效,软件结合CSR配置刷新 | 否 |
| Private | LiquidFailedValue | 温度点失效液冷调速值 | 是 |
| Private | ObtainTempFaildToValid | 硬盘调速策略温度值获取失败时该调速策略生效 | 是 |
| Private | OriginFailedValue | 失效调速策略CSR原始值 | 否 |
| Private | OriginMaxAllowedTemperatureCelsius | 满转调速策略CSR原始值 | 否 |
| Private | OriginSmartCoolingTargetTemperature | 智能调速模式调速策略CSR原始值 | 否 |
| Private | Slot | 槽位号,RequirementId后8位 | 否 |
| Private | SmartCoolingTargetTemperature | 智能调速模式策略,即EnergySaving/HighPerformance/LowNoise 三种模式下的目标温度值 | 是 |
"CoolingRequirement_1_41": { //说明:一个温度点对应一个CoolingRequirement对象,用于关联硬件温度和配置目标/告警调速;
"RequirementId": 41, //ID号,整机角度必需唯一,CoolingArea对象通过这个ID来绑定CoolingRequirement,BMC已在整理规范,后续会发布到社区,作为调试ID的配置约束。
"MonitoringStatus": "<=/CoolingConfig_1.SysSSDsMaxTemperature |> expr($1 == 0 ? 1 : 0)",//当前温度传感器的状态,配置为0代表温度传感器一直正常,其他值都代表温度传感器异常。
"MonitoringValue": "<=/CoolingConfig_1.SysHDDsMaxTemperature",//关联该调速对象的温度值,一般从单板温度传感器获取数值,这个属性不能引用传感器的Reading值。CoolingRequirement对象有些配置在其他单板上面,就是因为需要从其他单板上面获取温感的文档。
"FailedValue": 0, //温度状态异常后的异常调速转速,不配代表温度点异常不触发异常调速,默认值为0。举例:当MonitoringStatus不为0时(即传感器异常),这个时候会把FailedValue的值赋值给TargetTemperatureCelsius属性。
"TargetTemperatureCelsius": 62, //当前调速目标值(EnergySaving(节能模式)模式目标值)。参考《整机系统风扇调速策略》进行配置,文件没有说明为哪种调试模式即EnergySaving(节能模式)。
"MaxAllowedTemperatureCelsius": 67, //目标调速满转/触发全速门限温度。参考《整机系统风扇调速策略》数值
"TargetTemperatureRangeCelsius": [], //目标温度允许范围,用户自定义温度允许的范围值,在自定义调速模式下使用。
"ThresholdValue": [], //和BMC开发团队对齐,该对象可以删除,今后配置删除。
"AlarmSpeed": [], //和BMC开发团队对齐,该对象可以删除
"SmartCoolingTargetTemperature": [], //EnergySaving(节能模式)、HighPerformance(高性能模式)、LowNoise(低噪音模式)三种模式下的目标温度值,不需要区分的话不配即可。配置举例:"SmartCoolingTargetTemperature": [90, 85, 95] ,即EnergySaving(节能模式)目标值为90、HighPerformance(高性能模式)目标值为85、LowNoise(低噪音模式)目标值为95.
"CustomSupported": false, //是否支持Custom(自定义模式)目标值,false:不支持,true:支持。为false时,CustomTargetTemperatureCelsius不需要关注。
"CustomTargetTemperatureCelsius": 255 //Custom(自定义模式)模式下目标温度值。当CustomSupported为true才生效。
},配置举例:其中没有对智能调速模式的要求,则默认为即EnergySaving(节能模式),则调速目标值为节能调速目标值,即TargetTemperatureCelsius配置成62,触发全速门限为67,即MaxAllowedTemperatureCelsius为67。
3.3.5.4 CoolingArea
从整机视角,每一个CoolingRequirement对象都需要配置一个CoolingArea(包含单板CSR上配置的CoolingRequirement ,也需要在PSR中进行配置),CoolingArea的作用是将实际物料风扇和调速策略关联在一起。
| Interface/Private | 属性/方法 | 描述 | 是否由CSR配置 |
|---|---|---|---|
| bmc.kepler.Systems.CoolingArea | AreaId | 调速域Id,用不同的AreaId来区分不同调速区域 | 是 |
| bmc.kepler.Systems.CoolingArea | RequirementIdx | 目标调速策略Id,用来区分不同目标调速策略 | 是 |
| bmc.kepler.Systems.CoolingArea | PolicyIdxGroup | 线性调速策略Id组,用来记录不同线性调速策略 | 是 |
| bmc.kepler.Systems.CoolingArea | FanIdxGroup | 调速域风扇组,用来记录参与该区域调速的风扇id | 是 |
| Private | LiquidCoolingDeviceGroup | 调速域液冷器件组,用来记录参与该区域调速的液冷器件id | 是 |
| Private | Priority | 优先级,当存在相关AreaId的CoolingArea对象,以高优先级对象生效 | 是 |
"CoolingArea_1_41": {
"AreaId": 41, //ID号,整机角度必需唯一,,BMC已在整理规范,后续会发布到社区,作为调试ID的配置约束。
"RequirementIdx": 41, //填入需要绑定CoolingRequirement对象的RequirementId。
"PolicyIdxGroup": [], //若无线性调速模式CoolingPolicy,不需要填。举例:如果一个硬盘调试即存在CoolingPolicy线性调试策略,又存在CoolingRequirement单点调速策略,则肯定存在对应ID,即RequirementIdx和PolicyIdxGroup都需要配置
"FanIdxGroup": [ //绑定风扇组ID,风扇组ID来自于风扇板Fan对象的ID
1,
2,
3,
4,
5,
6,
7
]
},配置举例 其中风扇组序号为Fan1/2/3/4/5/6/7。实际和物料上风扇ID对应关系参考3.5.10 FanGroup章节。
注意:如果一个组件既有线性调试需求CoolingPolicy,又有单点调试策略CoolingRequirement,PolicyIdxGroup需要绑定所有调速模式下CoolingPolicy对象的PolicyIdx。
"CoolingArea_1_6": {
"AreaId": 6,
"RequirementIdx": 6, //填入需要绑定CoolingRequirement对象的RequirementId。
"PolicyIdxGroup": [ //需填入所有模式下CoolingPolicy对象的PolicyIdx。
6,
7,
8,
9
],
"FanIdxGroup": [ //绑定风扇组ID,风扇组ID来自于风扇板Fan对象的ID
1,
2,
3,
4,
5,
6,
7
]
},3.3.5.5 PowerStrategy
用于描述整机供电策略对象,包括主备供电和功率封顶电源策略,基于实际硬件形态与需求进行配置。
| Interface/Private | 属性/方法 | 描述 | 是否由CSR配置 |
|---|---|---|---|
| bmc.kepler.Systems.PowerStrategy | PowerWorkingMode | 系统电源期望主备模式 | 是(配置初始默认值,当前仅支持LoadBalancing) |
| bmc.kepler.Systems.PowerStrategy | PowerActualWorkingMode | 系统电源实际主备模式 | 否 |
| bmc.kepler.Systems.PowerStrategy | PowerLimitEnabled | 功耗封顶使能状态 | 是(配置初始默认值) |
| bmc.kepler.Systems.PowerStrategy | PowerLimitValue | 功耗封顶值 | 是(配置初始默认值) |
| bmc.kepler.Systems.PowerStrategy | PresetLimitInWatts | 功率封顶预设值 | 否 |
| bmc.kepler.Systems.PowerStrategy | ExpectedActivePSU | 期望的主用电源列表 | 否 |
| bmc.kepler.Systems.PowerStrategy | MaxPowerLimitInWatts | 功耗封顶上限值 | 否 |
| bmc.kepler.Systems.PowerStrategy | MinPowerLimitInWatts | 功耗封顶下限值 | 否 |
| bmc.kepler.Systems.PowerStrategy | WorkModeConfigurable | 是否支持电源主备模式设置 | 否 |
| bmc.kepler.Systems.PowerStrategy | PowerLimitFailed | 功耗封顶失败状态 | 否 |
| bmc.kepler.Systems.PowerStrategy | PowerLimitActivated | 功耗封顶触发状态 | 否 |
| bmc.kepler.Systems.PowerStrategy | PowerLimitExceptionSupported | 是否支持功耗封顶失败动作设置 | 是 |
| bmc.kepler.Systems.PowerStrategy | PowerLimitExceptionLogEvent | 功耗封顶动作记录事件日志(已废弃) | 是 |
| bmc.kepler.Systems.PowerStrategy | PowerLimitException | 功耗封顶失败动作 | 是(配置初始默认值) |
| bmc.kepler.Systems.PowerStrategy | DeepSleep | 深度休眠使能 | 否 |
| bmc.kepler.Systems.PowerStrategy | PowerLimitWhenSteady | 功率封顶是否受限于BMC初始化完成 | 否 |
| bmc.kepler.Systems.PowerStrategy | NormalAndRedundancy | N+R使能状态 | 否 |
| bmc.kepler.Systems.PowerStrategy | DeepSleepSupported | 是否支持电源深度休眠 | 是(配置功能是否支持) |
| bmc.kepler.Systems.PowerStrategy | NormalAndRedundancySupported | 是否支持N+R设置 | 是(配置功能是否支持) |
| bmc.kepler.Systems.PowerStrategy | ActiveStandbySupported | 是否支持系统电源主备模式设置 | 是(配置功能是否支持) |
| bmc.kepler.Systems.PowerStrategy | PowerCappingSupported | 是否支持功耗封顶设置 | 是(配置功能是否支持) |
| bmc.kepler.Systems.PowerStrategy | PSUsOutputVoltageLow | N+R压差是否异常 | 否 |
| bmc.kepler.Systems.PowerStrategy | RedundancyFailure | 冗余电源是否失效 | 否 |
| bmc.kepler.Systems.PowerStrategy | PowerPredictSupported | 是否支持功耗预测功能 | 是(配置功能是否支持) |
| bmc.kepler.Systems.PowerStrategy | EnergyEfficiencyOptimizationSupported | 是否支持智能能效寻优(预留) | 是(配置功能是否支持) |
| bmc.kepler.Systems.PowerStrategy | EnergySavingSupported | 是否支持节能功能(预留) | 是(配置功能是否支持) |
| bmc.kepler.Systems.PowerStrategy | PowerLimitMode | 功耗封顶模式 | 否 |
| bmc.kepler.Systems.PowerStrategy | PSUsUnavailableOfflineCause | 电源不可用原因 | 否 |
| bmc.kepler.Systems.PowerStrategy | PSUsOutputCurrentImbalance | 系统电源输出不均流 | 否 |
| bmc.kepler.Systems.PowerStrategy | HighPowerThresholdWatts | 系统功率过高告警阈值(不发送变化通知) | 是 |
| bmc.kepler.Systems.PowerStrategy | PowerCappingControlMode | 功耗封顶控制模式 | 是 |
| bmc.kepler.Systems.PowerStrategy | RedundancyMode | 系统电源冗余模式 | 是 |
| Private | Id | 对象Id | 否 |
| Private | ExpectedActivePSUList | 期望的主用电源列表(字符串) | 否 |
| Private | ReviseParam | 功耗封顶下限值计算系数 | 是 |
| Private | CustomPSActiveStandby | 是否自定义主备模式条件 | 否 |
| Private | PSActiveStandbyMaxLevel | 主备模式功耗切换上限 | 否 |
| Private | PSActiveStandbyMinLevel | 主备模式功耗切换下限 | 否 |
| Private | iRMHeartBeatTime | 管理板心跳时间 | 否 |
| Private | PowerCappingDevices | 功耗封顶设备类型 | 是 |
| Private | CapUpperThresholdPercent | 功耗封顶开启阈值百分比(已废弃) | 是 |
| Private | CapLowerThresholdPercent | 功耗封顶恢复阈值百分比(已废弃) | 是 |
| Private | CapStopThresholdPercent | 功耗封顶停止阈值百分比(已废弃) | 是 |
| Private | IsSupportPowerLimitMode | 是否支持封顶模式 | 是 |
| Private | AllowableMinPowerLimitInWatts | 功耗封顶下限值 | 是 |
| Private | NonCappedStaticPowerWatts | 不参与封顶的静态功耗值, 该属性在不为0xffffffff时有效 | 是(若不支持静态功耗封顶,则无需配置) |
"PowerStrategy_1": {
"PowerWorkingMode": "LoadBalancing", //电源供电模式配置,--补充全部模式
"PowerLimitValue": 9999, //功率封顶值,若功率封顶功能已使能,超过该值则触发功率封顶
"PowerLimitEnabled": false, //功率封顶当前状态(是否已触发),用于提供功耗封顶状态监测标志。BMC软件自动刷新。
"PowerLimitFailed": false, //功率封顶失败状态(是否封顶失败),用于监测功耗封顶操作是否失效,根据产品需求,可以用于功耗封顶失败告警触发条件。BMC软件自动刷新。
"PSUsOutputVoltageLow": false, //N+R压差是否异常(主用电源输入电压和备用电源输出电压是否偏差超过5)
"RedundancyFailure": false, //用于检测电源数量,整机运行过程中,若电源数量少于整机启动时电源数量,则BMC软件会置为true(1)
"PowerLimitActivated": false, //功率封顶状态是否触发,当前仅涉及CPU,触发时表明对CPU进行了降频,通过其状态监控,判断CPU是否降频,可以配置相关告警提示。
"PowerCappingSupported": true, //功率封顶功能使能,true:打开,false:关闭。
"PowerLimitExceptionSupported": true, //是否支持功率封顶失败操作,如果BMC界面配置了功率封顶失败策略为“下电”,只有配置为true,当前功率封顶失败后才会执行下电操作。
"DeepSleepSupported": false, //整机是否支持深度休眠模式(只有当电源主备模式生效后配置才有效)
"ActiveStandbySupported": false, //整机是否支持电源主备模式功能,true:支持,false:不支持。
"NormalAndRedundancySupported": false//整机是否支持N+R备电功能,true:支持,false:不支持。
},3.3.5.6 PowerConfiguration
整机如果存在多电源模块供电场景,但有可能只用单电源供电,单电源供电场景是否支持对其相关固件进行升级,需要配置该对象。--风冷机架PSR,对比差异。描述场景
| Interface/Private | 属性/方法 | 描述 | 是否由CSR配置 |
|---|---|---|---|
| Private | SinglePsuSupport | 是否支持单个电源升级标记, 1:支持,0:不支持 | 是 |
"PowerConfiguration_1": {
"SinglePsuSupport": 1 //如果存在主从供电场景,当只有单电源供电场景,是否支持给单电源相关组件进行固件升级。1:支持给单电源固件升级;0:支持给单电源固件升级。
},3.3.5.7 EnergyMetric
用于描述整机功耗相关信息统计,当前仅两个配置由CSR配置:1.用作告警输入值或者告警门限;2.风扇功耗数值用于BMC界面显示。其余信息由BMC软件刷新
| Interface/Private | 属性/方法 | 描述 | 是否由CSR配置 |
|---|---|---|---|
| bmc.kepler.Systems.EnergyMetric | SystemPower | 系统输入功率 | 否 |
| bmc.kepler.Systems.EnergyMetric | SystemOutputPower | 系统输出功率 | 否 |
| bmc.kepler.Systems.EnergyMetric | HighPowerThresholdWatts | 系统功率过高告警阈值(发送变化通知) | 否 |
| bmc.kepler.Systems.EnergyMetric | PowerConsumption | 累计耗电量 | 否 |
| bmc.kepler.Systems.EnergyMetric | MaxConsumedWatts | 系统最大功率 | 否 |
| bmc.kepler.Systems.EnergyMetric | MaxConsumedOccurredTime | 峰值功率出现时间 | 否 |
| bmc.kepler.Systems.EnergyMetric | MinConsumedWatts | 系统最小功率 | 否 |
| bmc.kepler.Systems.EnergyMetric | StatisticsCollectedTime | 功耗数据开始统计时间 | 否 |
| bmc.kepler.Systems.EnergyMetric | AverageConsumedWatts | 系统平均功率(U32) | 否 |
| bmc.kepler.Systems.EnergyMetric | HeatKcal | 电源消耗热量 | 否 |
| bmc.kepler.Systems.EnergyMetric | EnergySavedPercent | 省电百分比 | 是 |
| bmc.kepler.Systems.EnergyMetric | EnergySavedKwh | 省电总量KWh | 否 |
| bmc.kepler.Systems.EnergyMetric | CarbonEmissionsReducedKg | 减少碳排量 | 否 |
| bmc.kepler.Systems.EnergyMetric | FanTotalPowerWatts | 风扇总功耗 | 是 |
| bmc.kepler.Systems.EnergyMetric | PredictedPowerSavedKwh | 预计节省功耗 | 否 |
| bmc.kepler.Systems.EnergyMetric | PredictedPowerSavedPercent | 预计节省功耗百分比 | 否 |
| bmc.kepler.Systems.EnergyMetric | TotalPowerSavedKwh | 累计节省能耗 | 否 |
| bmc.kepler.Systems.EnergyMetric | TotalPowerSavedPercent | 累计节省功耗百分比 | 否 |
| bmc.kepler.Systems.EnergyMetric | PowerPredictStatus | 功耗预测模型状态 | 否 |
| bmc.kepler.Systems.EnergyMetric | PowerPredictDescription | 功耗预测工作状态描述 | 否 |
| bmc.kepler.Systems.EnergyMetric | HistoryPowerAverageWatts | 节能特性开启前平均功率 | 否 |
| bmc.kepler.Systems.EnergyMetric | MinPowerWatts | 当前系统支持的最小功耗(预留) | 否 |
| bmc.kepler.Systems.EnergyMetric | MaxPowerWatts | 当前系统支持的最大功耗(预留) | 否 |
| Private | AveragePower | 平均功率(double类型) | 否 |
| Private | AverageCnt | 平均功率计算次数 | 否 |
| Private | InstantAveragePower | 瞬时平均功率 | 否 |
| Private | ACBootPSCount | AC上电系统电源个数 | 否 |
| Private | PSPresentCount | 电源在位个数 | 否 |
| Private | IsThresholdManuallySet | 用户是否设置过系统功耗阈值 | 否 |
| Private | DataStartTime | 功耗预测数据获取起始时间 | 否 |
"EnergyMetric_1": {
"SystemPower": 0, //整机系统输入功率,硬件可在PSR中配置相关传感器显示其数值。数值由BMC软件刷新。
"SystemOutputPower": 0, //整机系统输出功率,硬件可在PSR中配置相关传感器显示其数值。数值由BMC软件刷新。
"HighPowerThresholdWatts": 65535,//电源功率过高告警阀值,数值由BMC软件刷新,用于功率过高的告警阀值判断。
"FanTotalPowerWatts": 0 //风扇总功耗,由硬件对其进行赋值,注意使用表达式计算的时候应该将结果向上取整,同时部分风扇板由于风扇内部电路耗电和传感器精度,根据实测结果可能需要屏蔽0.xw之内的功耗回显为0(举例920g配置为:"FanTotalPowerWatts": "<=/Scanner_Fan_Pwr.Value |> expr($1 > 9 ? ($1 * 0.075 + 0.975) : 0 )" )。注意:有些项目风扇板应该没有功耗计算方法,CPLD/MCU无风扇功耗数值上报,因此无法赋值,会存在BMC界面风扇功耗显示未0的情况,进而有部分方案这个风扇功耗由BMC进行算法赋值。有些场景CPLD可以上报920B,如配置"FanTotalPowerWatts": "<=/Scanner_Fan_Pwr.Value;<=/Scanner_EXPpcbver.Value |> expr(($2 >= 2) ? $1 : (-0.000000000000000000000001392242 * $1 * $1 * $1 * $1 * $1 * $1 + 0.000000000000000000163618116237 * $1 * $1 * $1 * $1 * $1 - 0.00000000000000714729233014839 * $1 * $1 * $1 * $1 + 0.000000000141146266763049 * $1 * $1 * $1 - 0.00000124480707999752 * $1 * $1 + 0.0196497990638136 * $1))",计算出风扇功耗。
}3.3.5.8 ThermalConfiguration
用于描述整机散热配置信息,包括standby下风扇是否可以运转、风扇起始槽位。
| Interface/Private | 属性/方法 | 描述 | 是否由CSR配置 |
|---|---|---|---|
| Private | StandbyFan | standby下风扇是否可以运转, 1:可以,0:不可以 | 是 |
| Private | FanStartSlot | 风扇起始槽位,下标为风扇板槽位,值为风扇起始槽位,多风扇板场景使用 | 是 |
| Private | Id | 对象Id | 是 |
"ThermalConfiguration_1":
{
"StandbyFan": 1, //Standby模式下风扇是否可以运转,1:可以;0:不可以。
"FanStartSlot": [] //多风扇板场景需要配置,当前配置为空是因为门禁要求配置FanStartSlot,对齐配置为空。
},3.3.5.9 BasicCoolingConfig
如果有多个FanGroup对象,且要求风扇组之间的转速控制存在关联关系,则需要配置该对象,与FanGroup配合使用。
| Interface/Private | 属性/方法 | 描述 | 是否由CSR配置 |
|---|---|---|---|
| Private | FanGroupSpeedDiffThresholdPercent | 风扇组转速差阈值百分比,默认值表示不进行转速差计算 | 是 |
| Private | PsuFanSpeedCalibration | psu风扇转速校准值,默认值表示不进行psu转速下发 | 是 |
| Private | Id | 对象Id | 是 |
"BasicCoolingConfig ": {
"FanGroupSpeedDiffThresholdPercent": 25 //风扇组转速差阈值百分比
}FanGroupSpeedDiffThresholdPercent:风扇组转速差阈值百分比,如果默认值32767表示不进行转速差计算。
3.3.5.10 FanGroup
用于描述风扇组转速控制信息,若一个整机环境中有多个风扇组,且不同风扇组之间转速控制存在关联关系,如风扇组1,2,3规定比风扇组4转速低20%,则需配置该对象对风扇组转速控制信息进行管理。
| Interface/Private | 属性/方法 | 描述 | 是否由CSR配置 |
|---|---|---|---|
| bmc.kepler.Chassis.FanGroup | Id | 风扇组Id | 是 |
| bmc.kepler.Chassis.FanGroup | FanSlots | 风扇组内包含风扇的槽位号 | 是 |
| bmc.kepler.Chassis.FanGroup | SpeedPercent | 基于风扇组内风扇修正后的转速,并统一下发至所有风扇 | 是 |
| bmc.kepler.Chassis.FanGroup | ExpectedSpeedPercent | 风扇组分组下发转速 | 否 |
| Private | ResetSpeedPercent | BMC重启阶段转速策略 | 是 |
"FanGroup_1": {
"Id": 1, //风扇组Id,代表不同的风扇组合,要求整机环境唯一
"FanSlots": [1, 2, 3, 4] //风扇slot来自于风扇板下面风扇对象Fan的FanId。
}
"FanGroup_2": {
"Id": 2, //风扇组Id,代表不同的风扇组合,要求整机环境唯一
"FanSlots": [5, 6, 7, 8] //风扇slot来自于风扇板下面风扇对象Fan的FanId。
}配置场景举例,根据热传递《整机系统风扇调速策略》,其中有要求启动时,Fan1/2/3/4和Fan5/6/7/8之间的转速不一样,则需要配置两个风扇组:FanGroup_1、FanGroup_2。
FanSlots中的值来自于风扇板CSR的Fan对象FanId。
3.3.5.11 AirCoolingConfig
用于描述风冷散热配置,包括风扇控制模式、失联状态场景风扇转速级别、开机风扇初始转速百分比、手动调节风扇转速允许的调速区间等信息,新增风扇散热配置相关属性在改类下进行拓展
| Interface/Private | 属性/方法 | 描述 | 是否由CSR配置 |
|---|---|---|---|
| bmc.kepler.Systems.AirCoolingConfig | CtrlMode | 风扇控制模式(自动/手动/混合) | 否 |
| bmc.kepler.Systems.AirCoolingConfig | CtrlModePersistType | 风扇控制模式的持久化类型;0:不持久化、1:复位持久化、2:掉电持久化 | 否 |
| bmc.kepler.Systems.AirCoolingConfig | CtrlModeResetPersist | 复位持久化的风扇控制模式 | 否 |
| bmc.kepler.Systems.AirCoolingConfig | CtrlModePoweroffPersist | 掉电持久化的风扇控制模式 | 否 |
| bmc.kepler.Systems.AirCoolingConfig | TimeOut | 手动模式下的超时时间 | 否 |
| bmc.kepler.Systems.AirCoolingConfig | ManualSpeedPercent | 手动模式下的转速级别 | 否 |
| bmc.kepler.Systems.AirCoolingConfig | ManualSpeedPercentResetPersist | 复位持久化的手动模式下的转速级别 | 否 |
| bmc.kepler.Systems.AirCoolingConfig | ManualSpeedPercentPoweroffPersist | 掉电持久化的手动模式下的转速级别 | 否 |
| bmc.kepler.Systems.AirCoolingConfig | SpeedPercentRange | 手动设置转速级别允许范围 | 是 |
| bmc.kepler.Systems.AirCoolingConfig | MinAllowedSpeedPercent | 失联状态场景风扇转速级别 | 是 |
| bmc.kepler.Systems.AirCoolingConfig | InitialSpeedPercent | 开机风扇初始转速百分比 | 是 |
| bmc.kepler.Systems.AirCoolingConfig | ActiveAlgorithm | 实时生效的算法 | 否 |
| bmc.kepler.Systems.AirCoolingConfig | MaxAllowedSpeedPercent | 风扇自动调速允许的最大转速百分比 | 是 |
| 配置样例: |
"AirCoolingConfig": {
"SpeedPercentRange": [10,100], //手动调节风扇转速运行的
"InitialSpeedPercent": 100, //初始转速百分比,系统开机过程中,软件调速功能还未生效前,默认的初始风扇转速百分比
"MaxAllowedSpeedPercent": "<=/Scanner_LiquidLeakage.Value |> expr((($1 != 0) ? 70 : 100))" //风扇自动调速允许的最大转速百分比
}例:要求风扇手动转速区间为10%-100%,因此需要对SpeedPercentRange数值进行配置。
3.3.5.12 ThermalSubsystem
散热器件的总功耗标识,软件会自动刷新,如果不需要该数值调用,可以不配置。
| Interface/Private | 属性/方法 | 描述 | 是否由CSR配置 |
|---|---|---|---|
| bmc.kepler.Chassis.ThermalSubsystem.Metrics | TotalPowerWatts | 散热器件总功耗 | 是 |
| bmc.kepler.Chassis.ThermalSubsystem.Metrics | EnergyConsumptionkWh | 散热器件累计耗电量,由软件根据TotalPowerWatts刷新 | 否 |
| bmc.kepler.Chassis.ThermalSubsystem.Metrics | ResetTime | 散热器件累计耗电量开始统计时间,由软件刷新 | 否 |
| Private | Id | 对象Id | 否 |
| 配置样例: |
"ThermalSubsystem": {
"TotalPowerWatts": 0 //散热器件总功耗数值,BMC软件会进行数值刷新。
}3.3.5.13 MPCConfig
MPC配置,只有配置该对象后才能使用MPC功能。
| Interface/Private | 属性/方法 | 描述 | 是否由CSR配置 |
|---|---|---|---|
| bmc.kepler.Systems.MPCConfig | Enabled | MPC是否使能,默认为false | 否 |
| bmc.kepler.Systems.MPCConfig | LastStartTime | 最近一次MPC开启时间 | 否 |
| bmc.kepler.Systems.MPCConfig | Status | MPC模型状态,当前存在5种取值类型,Idle空闲状态,Training训练状态,Active生效状态,Inactive不生效状态,Unavailable不可用状态 | 否 |
| bmc.kepler.Systems.MPCConfig | TotalPowerSavedKwh | MPC累计节省能耗,千瓦时 | 否 |
| Private | Id | 对象Id | 否 |
| 配置样例: |
"MPCConfig_1": {
"Enabled": false // MPC是否使能,默认为false,代码刷新
}3.3.6 液冷场景专用
3.3.6.1 LeakDetection
漏液检测策略管理,可获取漏液状态,针对漏关断阀策略与漏液上下电策略进行设置,并管理策略的使能状态
| Interface/Private | 属性/方法 | 描述 | 是否由CSR配置 |
|---|---|---|---|
| bmc.kepler.Chassis.LeakDetection | LeakValvePolicy | 漏液关断阀策略,0:不操作,1:自动关断 | 是 |
| bmc.kepler.Chassis.LeakDetection | LeakPowerPolicy | 漏液上下电策略,0:不操作,1:自动下电 | 是 |
| bmc.kepler.Chassis.LeakDetection | Enabled | 是否使能漏液动作,false:不使能,true:使能 | 是 |
| bmc.kepler.Chassis.LeakDetection | LeakState | 漏液状态:0:无漏液,1:轻微漏液,2:严重漏液 | 是 |
| 配置样例: |
"LeakDetection_1": {
"LeakValvePolicy": 0, //当出现漏液时,是否需要关断阀门。0:不关断,1:关断。
"LeakPowerPolicy": 0, //当出现漏液时,是否需要对系统进行下电。0:不下电,1:下电。
"Enabled": true, //漏液功能状态,true:使能这个功能;false:不使能。
"LeakState": "<=/Scanner_LiquidLeakage.Value |> expr((($1 != 0) ? 2 : 0))"//硬件需要传递状态给BMC,其中0代表没有漏液,1代表轻微漏液,2代表严重漏液。
}