0 PSR定义及整体框架
0.1 定义
PSR是站在软件的角度来定义整机硬件“是什么,有什么,能做什么”,其主要是从整机视角配置整机所需要的描述信息及功能。
0.2 PSR结构说明
一个完整的PSR由三个部分组成,第一部分为FormatVersion、DataVersion、DataType组成的版本描述信息,第二部分为管理拓扑:ManagementTopology,第三部分为管理对象:Objects。
{
"FormatVersion" : "3.00", //PSR代次版本号
"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" :
{
... //本组件/部件内需要描述的业务对象,每个业务对象都是一个抽象的功能实体。
}
}1 PSR版本描述信息配置说明
PSR版本描述信息配置比较简单,每次版本迭代,只需要修改DataVersion。
"FormatVersion" : "3.00", //PSR代次版本号
"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交互功能。
"Connector_PSR_EEP": {
"Bom": "14100513",
"Slot": 1,
"Position": 10,
"Presence": 1,
"Id": "",
"AuxId": "",
"Buses": [
"I2c_8",
"I2c_2"
],
"SystemId": 1,
"ManagerId": "1",
"ChassisId": "1",
"SilkText": "PSR",
"IdentifyMode": 3
}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"
]
}
}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”。
配置举例:假设整机有两种接线配置,其中对于riser1有两种不同的riser卡配置场景。
"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对象。
}
]
}因为是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。
部分机型BMC接线和其他机型不一致,需要配置BMC的槽位以同步BDF,见03 EXU/00 EXU配置指导书.md中3.4.10节BMC卡rootBDF自发现。
3.1.2 Dimension
整机高度信息配置,整机高度信息需要配置,给软件提供整机高度数据接口。
"Dimension_1": {
"HeightU": 1 //整机高度,单位U,目前了解到BIOS会获取整机高度。
}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状态。
3.2.3 EEPROM
天池架构规范规定每个组件上必须存在一个在I2C总线上地址为0xAE的存储器件,当前均为Eeprom器件,用于存储硬件自描述信息,包含头部、电子标签、组件自描述信息(CSR/PSR)以及扩展信息等。天池规范定义了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 组件管理
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, //传感器读值掩码,决定是否能对外显示门限
"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+产品组件类型+挂耳模块部件编码组成。
"Type": "PSR", //升级对象类似,描述升级对象是PSR还是CSR,PSR配置为PSR
"Version": "${DataVersion}", //版本号,默认采用引用语法,${DataVersion}
"StorageChip": "#/Eeprom_1", //升级对象,需要绑定PSR升级的EEPROM对象
"SoftwareId": "HWSR-xxx" //编码信息,配置格式按HWSR-单板名称,其中单板名称在PDM上查询挂耳模块部件。
}3.3.4 对外数据接口
3.3.4.1 Product
Product对象承载服务器整机的标准化配置信息,包含以下核心属性:整机名称、整机示意图、产品整机唯一产品标识符(ProductUniqueID)及厂商ID(ProductVendorID),其核心功能为向BMC提供整机数据接口。特别说明:通过VendorID与ProductID的二进制位拼接算法,可生成具有唯一性的设备识别码ProductUID(格式:ProductVendorID<< 16 | ProductUniqueID)。
"Product_1": {
"ProductName": "xxx", //整机名称——用于BMC界面显示,配置完BMC登录后,界面左上角会显示该名称。
"ProductAlias": "", //产品别名——软件/redfish/v1/SystemOverview、/UI/Rest/Overview相关接口有调用该数据,PSR需要配置一个空的载体给软件,BMC会自动刷新。——要求软件自动带出。
"ProductPicture": "img_01", //BMC界面整机显示的图片——BMC软件会针对整机显示的图片进行编号,如img_01,img_02,这里配置整机需要显示正确的图片编号。
"ProductUniqueID": "0xyyy", //产品唯一ID——一个整机产品的编码。
"ProductVendorID": "zzz" //厂商ID,整机ID的前八位即厂商ID
}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": "XXX" //整机UID组成:厂商ID+产品组件类型+挂耳模块部件编码组成。
}3.3.5 能效管理
1.Coolling模块说明:CoolingPolicy为线性调速策略,CoolingRequirement为某个温度点调速策略(可以理解成PID调速),CoolingConfig承载了Cooling对象初始化配置及变量调用 ,CoolingFan当前配置在风扇板中,所有Cooling模块最终由CoolingArea承载。CoolingArea分别通过RequirementIdx、FanIndxGroup和PolicyIdxGroup来关联温度点(CoolingRequirement)、参与调速的风扇(CoolingFan)和调速策略(CoolingPolicy),CoolingArea与CoolingRequirement应该一一对应;CoolingArea只能配置到PSR中(区分单电源和双电源);CoolingRequirement一般跟随单板所在的SR配置
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属性中需要将转速范围配置成10%—100%,因此LevelPercentRange配置为[10,100]。
| 风扇手动调速区间 | 风扇手动调速精度 | 手动控制风扇序号 |
|---|---|---|
| 10% - 100% | 1% | 1、能控制所有风扇一起调速 2、能控制单个风扇进行调速 |
3.3.5.2 CoolingPolicy
线性调速功能配置,一个CoolingPolicy对象就是一条调速曲线,如一台服务器整机中有进风口部分(一般是前置背板)、有网卡、有硬盘等,如果其存在线性调速功能需求(以网卡举例:如果不同温度区间有对应不同风扇转速的要求),这个时候就需要配置一个CoolingPolicy对象。
| 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原始值 | 否 |
配置举例:如下图所示,该调速策略的生效条件为调速模式为节能模式("EnergySaving")、硬盘背板"XXX"在位、风扇型号为"02315BQL 4056++",调速迟滞量为1。
"CoolingPolicy_1_6": {
"PolicyIdx": 6, //ID号,整机角度必需唯一,CoolingArea对象通过这个ID来绑定CoolingPolicy。
"ExpCondVal": "EnergySaving",//调速策略预期生效模式,模式有Custom(自定义模式)、HighPerformance(高性能模式)、LowNoise(低噪音模式)、EnergySaving(节能模式)、LiquidCooling(液冷模式)。
"ActualCondVal": "<=/CoolingConfig_1.SmartCoolingMode",//当这个值等于ExpCondVal时,该调速策略生效。从CoolingConfig中获取当前智能调速的模式状态,当前该模式状态等于ExpCondVal属性配置的模式时,该CoolingPolicy_1_6线性调速模式才生效。
"Hysteresis": 1,//调速迟滞量。
"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_6线性调速策略直接失效。
"HDDBackPlaneName": ["XXX"] //硬盘背板名称,需要和背板CSR中配置的HddBackplane对象中Name属性一样,如果获取整机所有HddBackplane对象的Name属性,没有找到"XXX",则该CoolingPolicy_1_6线性调速策略直接失效。
}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 三种模式下的目标温度值 | 是 |
配置举例:如下表所示,其中没有对智能调速模式的要求,则默认为即EnergySaving(节能模式),则调速目标值为节能调速目标值,即TargetTemperatureCelsius配置成62,触发全速门限为67,即MaxAllowedTemperatureCelsius为67。
| 机型 | 对应风扇序号 | 调速目标值 | 触发全速门限 | 传感器失效异常调速 |
|---|---|---|---|---|
| XXX | Fan1/2/3/4/5/6/7 | 62 | 67 | 80% |
"CoolingRequirement_1_41": { //说明:一个温度点对应一个CoolingRequirement对象,用于关联硬件温度和配置目标/告警调速;
"RequirementId": 41, //ID号,整机角度必需唯一,CoolingArea对象通过这个ID来绑定CoolingRequirement。
"MonitoringStatus": "<=/CoolingConfig_1.SysSSDsMaxTemperature |> expr($1 == 0 ? 1 : 0)",//当前温度传感器的状态,配置为0代表温度传感器正常,其他值都代表温度传感器异常。
"MonitoringValue": "<=/CoolingConfig_1.SysHDDsMaxTemperature",//关联该调速对象的温度值,一般从单板温度传感器获取数值,这个属性不能引用传感器的Reading值。CoolingRequirement对象有些配置在其他单板上面,就是因为需要从其他单板上面获取温感的文档。
"FailedValue": 80, //温度状态异常后的异常调速转速,不配代表温度点异常不触发异常调速,默认值为0。举例:当MonitoringStatus不为0时(即传感器异常),会将调速策略关联的风扇转速百分比拉到FailedValue。
"TargetTemperatureCelsius": 62, //当前调速目标值(EnergySaving(节能模式)模式目标值)。
"MaxAllowedTemperatureCelsius": 67, //目标调速满转/触发全速门限温度。
"TargetTemperatureRangeCelsius": [], //目标温度允许范围,用户自定义温度允许的范围值,在自定义调速模式下使用。
"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才生效。
}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对象,以高优先级对象生效 | 是 |
配置举例 其中风扇组序号为Fan1/2/3/4/5/6/7。实际和物料上风扇ID对应关系参考3.5.10 FanGroup章节。
"CoolingArea_1_41": {
"AreaId": 41, //调速区域ID,整机角度必需唯一。
"RequirementIdx": 41, //填入需要绑定CoolingRequirement对象的RequirementId。
"PolicyIdxGroup": [], //若无线性调速模式CoolingPolicy,不需要填。举例:如果一个硬盘调速即存在CoolingPolicy线性调速策略,又存在CoolingRequirement单点调速策略,则肯定存在对应ID,即RequirementIdx和PolicyIdxGroup都需要配置
"FanIdxGroup": [ //绑定风扇组ID,风扇组ID来自于风扇板Fan对象的ID
1,
2,
3,
4,
5,
6,
7
]
}注意:如果一个组件既有线性调速需求CoolingPolicy,又有目标调速策略CoolingRequirement,PolicyIdxGroup需要绑定所有调速模式下CoolingPolicy对象的PolicyIdx。
"CoolingArea_1_6": {
"AreaId": 6,
"RequirementIdx": 6, //该区域关联的CoolingRequirement对象的RequirementId。
"PolicyIdxGroup": [ //该调速区域在所有调速模式下关联的CoolingPolicy对象的PolicyIdx。
6,
7,
8,
9
],
"FanIdxGroup": [ //该调速区域关联的风扇ID数组,表示参与该区域调速的所有风扇的ID集合
1,
2,
3,
4,
5,
6,
7
]
}3.3.5.5 PowerConfiguration
整机如果存在多电源模块供电场景,但有可能只用单电源供电,单电源供电场景是否支持对其相关固件进行升级,需要配置该对象。
| Interface/Private | 属性/方法 | 描述 | 是否由CSR配置 |
|---|---|---|---|
| Private | SinglePsuSupport | 是否支持单个电源升级标记, 1:支持,0:不支持 | 是 |
"PowerConfiguration_1": {
"SinglePsuSupport": 1 //如果存在主从供电场景,当只有单电源供电场景,是否支持给单电源相关组件进行固件升级。1:支持给单电源固件升级;0:支持给单电源固件升级。
}3.3.5.6 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.7 BasicCoolingConfig
如果有多个FanGroup对象,且要求风扇组之间的转速控制存在关联关系,则需要配置该对象,与FanGroup配合使用。
| Interface/Private | 属性/方法 | 描述 | 是否由CSR配置 |
|---|---|---|---|
| Private | FanGroupSpeedDiffThresholdPercent | 风扇组转速差阈值百分比,默认值表示不进行转速差计算 | 是 |
| Private | PsuFanSpeedCalibration | psu风扇转速校准值,默认值表示不进行psu转速下发 | 是 |
| Private | Id | 对象Id | 是 |
"BasicCoolingConfig ": {
"FanGroupSpeedDiffThresholdPercent": 25 //风扇组转速差阈值百分比
}FanGroupSpeedDiffThresholdPercent:风扇组转速差阈值百分比,如果默认值32767表示不进行转速差计算。
3.3.5.8 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重启阶段转速策略 | 是 |
如果整机系统风扇调速策略要求启动时,Fan1/2/3/4和Fan5/6/7/8之间的转速不一样,则需要配置两个风扇组:FanGroup_1、FanGroup_2。调速策略举例:
| 转子数量 | 对应风扇序号 | 启动时固定PWM/转速(xx%) |
|---|---|---|
| 双转子 | Fan1/2/3//4 | 30% |
| 双转子 | Fan5/6/7//8 | 40% |
配置举例:
"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。
}FanSlots中的值来自于风扇板CSR的Fan对象FanId,如下所示:
"Fan_1": {
"FanId": 1,
"Slot": 1,
"Coefficient": 1,
"FrontPresence": "<=/Scanner_Fan1_Presence.Value",
"RearPresence": "<=/Scanner_Fan1_Presence.Value",
"FrontSpeed": "<=/Scanner_Fan1_FSpeed.Value",
"RearSpeed": "<=/Scanner_Fan1_RSpeed.Value",
"HardwarePWM": "#/Accessor_Fan1_PWM.Value",
"SystemId": 1,
"FrontStatus": 0,
"RearStatus": 0,
"MaxSupportedPWM": 255,
"IdentifySpeedLevel": 35,
"Position": "CLU",
"PowerGood": "<=/Scanner_PowerGood.Value"
}3.3.5.9 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], //风扇手动调速区间为10%-100%
"InitialSpeedPercent": 100, //初始转速百分比,系统开机过程中,软件调速功能还未生效前,默认的初始风扇转速百分比
"MaxAllowedSpeedPercent": "<=/Scanner_LiquidLeakage.Value |> expr((($1 != 0) ? 70 : 100))" //风扇自动调速允许的最大转速百分比
}3.3.5.10 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软件会进行数值刷新。
}