资源协作接口规范 ​

文档说明 ​

资源协作接口用于定义组件之间共享的资源能力及其承载关系。本文主要包含两类内容：

• 开发与配置说明：说明资源协作接口文件如何组织，Interface、ObjectPath、Message 如何配置，以及资源树命名和设计要求；
• 配置检查规则：说明资源接口、属性、方法、信号、资源对象以及跨模型管理关系需要满足的检查约束。

本文面向开发资源协作接口和进行接口配置检视的开发者。

1. 概述 ​

1.1 资源协作接口模型 ​

按照资源树模型，Interface 用于描述一类资源提供的属性、方法和信号；ObjectPath 用于描述具体资源对象路径，并组合一个或多个 Interface；Message 用于组件资源协作接口被访问时向访问者传递状态或错误信息。

整体关系如下：

Interface
├── Property
├── Method
└── Signal
      ↓
ObjectPath 组合一个或多个 Interface
      ↓
MDS 管理资源对象
      ↓
组件提供实际业务能力

1.2 目录结构与资源模型 ​

目录结构 ​

├── json
│   ├── intf
│   │   └── mdb
│   │       └── bmc
│   └── path
│       └── mdb
│           └── bmc
├── messages
│   ├── base.json
│   └── custom.json
└── proto

目录说明 ​

1. 资源协作接口与 MDS 一样，采用 json 格式描述，当前已经有部分使用 proto 格式描述，因此新增同级目录 json 用于存放 json 格式描述的资源协作接口，待全部完成转换后删除 proto 目录，并把 json 目录下面的子目录提升为一级目录。
2. 按照 DBus 的设计，Interface 可以看作是抽象的表示和行为，ObjectPath 可以看作是实例的类型，实例类型里面组合一个或多个 Interface，因此把资源协作接口的设计分为两部分，一部分是接口（Interface，在 json/intf 目录中），一部分是路径（ObjectPath，在 json/path 目录中）。
3. 在 intf 目录下面，按照 Interface 名称创建子目录层级，如接口名称 bmc.kepler.x.y.z，则在 bmc/kepler 下面创建子目录 x/y，创建接口描述文件 z.json。
4. 在 path 目录下面，按照 ObjectPath 名称创建子目录层级：
   1. 如 path 名称是 /bmc/kepler/x/y/z 或 /bmc/kepler/x/${SystemId}/y/z/${Id}，则在 bmc/kepler 目录下面创建子目录 x/y/z/，然后创建 path 描述文件，文件名不做约束。
   2. 例如 path 名称是 /bmc/kepler/Systems/${SystemId}/ThresholdSensors/${Id}，其对应的文件路径为 /bmc/kepler/Systems/ThresholdSensors/。
   3. 具体的 path 描述文件可以是 ThresholdSensor.json 或 ThresholdSensors.json，即 path 目录下存在如下两个文件：
      1. /bmc/kepler/Systems/ThresholdSensors/ThresholdSensor.json，在 MDS 数据模型中，类名是 ThresholdSensor，其 path 是 /bmc/kepler/Systems/${SystemId}/ThresholdSensors/${Id}。
      2. /bmc/kepler/Systems/ThresholdSensors/ThresholdSensors.json，在 MDS 数据模型中，类名是 ThresholdSensors，其 path 是 /bmc/kepler/Systems/${SystemId}/ThresholdSensors。
5. 消息（message）是组件（APP）的资源协作接口在被访问时向访问者传递的一种数据，主要用于北向接口访问后台资源时，通过消息向外传递系统的状态或错误等，参考 Redfish 的 message 定义，总体分为 base（Redfish 标准定义）和 custom（iBMC 自定义）两部分。

2. Interface 配置 ​

2.1 Interface 配置示例一 ​

{
    "bmc.demo.IDemo": {
        "virtual": true,
        "properties": {
            "Property1": {
                "baseType": "U8",
                "default": 0,
                "maximum": 127,
                "minimum": 1,
                "description": "abc"
            }
        },
        "methods": {
            "Method1": {
                "req": {
                    "ReqArg1": {
                        "baseType": "U8"
                    },
                    "ReqArg2": {
                        "baseType": "Array",
                        "items": {
                            "$ref": "#/defs/StructAbc"
                        }
                    }
                },
                "rsp": {
                    "RspArg1":{
                        "baseType": "U16"
                    }
                }
            }
        },
        "description": "this is an example"
    },
    "defs": {
        "StructAbc": {
            "MemVar1": {
                "baseType": "Boolean"
            },
            "MemVar2": {
                "baseType": "Enum",
                "$ref": "#/defs/EnumAbc"
            },
            "MemVar3": {
                "baseType": "Struct",
                "$ref": "#/defs/StructXyz"
            }
        },
        "StructXyz": {
            "MemVar4": {
                "baseType": "S64[]"
            },
            "MemVar5": {
                "baseType": "String",
                    "maxLength": 256,
                    "minLength": 1
            }
        },
        "EnumAbc": {
            "EnumVar1": 1,
            "EnumVar2": 2
        }
    }
}

说明 ​

1. bmc.demo.IDemo 表示接口名称。
2. virtual 表示接口是否能重载（主要指方法），可选字段，不写时表示 virtual 为 false。
3. properties 表示接口中的属性，属性名用大驼峰风格，baseType 表示属性的基本类型，default 表示属性的默认值（如果 baseType 是 Enum 时，default 则用枚举变量名称，比如这里的 EnumVar1）。
4. methods 表示接口中的方法，方法名称用大驼峰风格，req/rsp 分别表示方法的请求和响应，参数名称用大驼峰风格。
5. 如果 req/rsp 中存在复杂数据类型：
   1. 如果是结构体（参考 MemVar3），则 baseType 设置为 Struct，通过 $ref 指定具体的结构体定义，结构体成员变量使用大驼峰风格。
   2. 如果是结构体数组（参考 ReqArg2），则 baseType 设置为 Array，items 中通过 $ref 指定具体的结构体定义，结构体成员变量使用大驼峰风格。
   3. 如果是枚举（参考 MemVar2），则 baseType 设置为 Enum，通过 $ref 指定具体的枚举定义，枚举变量使用大驼峰风格。
6. 该规则描述同样适用于接口中的属性以及信号中的参数。
7. defs 表示本文件的属性或方法、信号参数的复杂类型定义，支持嵌套描述（如 StructAbc 的 MemVar3 仍然是结构体，其定义为 StructXyz）。
8. description 是注释说明，可选字段。

2.2 Interface 配置示例二 ​

{
    "bmc.demo.IDemo": {
        "properties": {
            "Property1": {
                "baseType": "U8",
                "options": {
                    "volatile": true
                }
            },
            "Property2": {
                "baseType": "U32",
                "options": {
                    "deprecated": true
                }
            },
            "Property3": {
                "baseType": "U8",
                "options": {
                    "explicit": true
                }
            },
            "Property4": {
                "baseType": "I32",
                "options": {
                    "emitsChangedSignal": "true"
                }
            }
        }
    }
}

说明 ​

options 表示资源协作接口中属性的能力选项，当前支持的能力包括：

1. volatile: 表示属性是否易变，如果取值为 true，则表示该属性的值不稳定，组件可以选择不监听该属性的变化信号，默认为 false。
2. deprecated: 表示属性是否弃用，如果取值为 true，则表示属性被弃用，默认为 false。
3. explicit: 表示属性值在属性名明确时才可见，如果取值为 true，则表示属性在 introspect（list 操作，不指定属性名）时不显示，只能在单独 Get（需要明确属性名）时才显示，默认为 false。
4. emitsChangedSignal: 表示是否发送属性变化信号，默认为 "true"。注意此选项的值不是 Boolean 类型而是 String 类型。
   1. 如果取值为 "false"，表示属性变化时不发送信号。
   2. 如果取值为 "const"，表示属性永不变化，不需要发送信号。
   3. 如果取值为 "true"，表示属性变化时发送信号，信号携带属性值。
   4. 如果取值为 "invalidates"，表示属性变化时发送信号，但信号不携带属性值。

2.3 关键字使用范围 ​

2.3.1 属性关键字 ​

除 default 关键字允许组件模型定义覆盖资源树接口定义，以下属性关键字仅资源树接口可定义。

2.3.2 方法关键字 ​

以下方法关键字仅资源树接口可定义。

2.3.3 信号关键字 ​

以下信号关键字仅资源树接口可定义。

2.4 Interface 基础规则 ​

Interface 除按前述结构进行配置外，还需要满足名称、唯一性和有效性要求。

2.4.1 接口名称 ​

资源接口名称必须为长度不超过 128 的非空字符串，由若干非空字符串通过 . 拼接，首段必须为 bmc。接口名称不满足长度、非空或分段格式要求时，应规范接口名称后再提交配置。

接口名称属于公共标识，修改已被使用的接口名称时，还需要同步检查资源对象对该接口的实现、MDS 对该接口的管理以及其它配置对该接口的引用，避免名称修改后产生悬空引用。

2.4.2 接口唯一性 ​

资源接口名称必须全局唯一。不同文件中定义相同接口名称会产生定义冲突，可能导致后加载定义覆盖前一份定义并引起业务异常。发现重名时，应修改或删除重复接口，并同步调整资源对象、MDS 及其它引用位置。

2.4.3 接口有效性 ​

资源接口中至少需要配置属性、方法或信号中的一种。三类成员均为空时，该接口不承载实际资源能力，应补充至少一种成员，或者删除无实际用途的接口定义。

2.5 Property 配置规则 ​

2.5.1 属性名称与唯一性 ​

资源属性名称必须为长度不大于 64 的非空字符串，并采用大驼峰格式；同一接口内属性名称必须唯一。属性重名会造成定义冲突，后加载属性可能覆盖先加载属性，因此应删除或重命名重复属性。

2.5.2 baseType ​

资源属性的 baseType 为必填字段。可使用的基础类型包括：

U8 U16 U32 U64
S8 S16 S32 S64
Boolean Double String

还可以使用当前接口中定义的 Dictionary、Struct、Enum 自定义类型，以及基础类型或自定义类型的数组类型。基础类型数组在类型后增加 []，例如 U8[]；自定义类型数组使用 Array，并通过 items 引用已存在的自定义类型。

缺少 baseType 或类型取值不在允许范围内时，属性无法正常管理。应补充 baseType，或将其修改为有效类型。

2.5.3 readOnly ​

readOnly 为必填字段，只能取 true 或 false。缺失或取值非法会影响属性的正常读写控制，应补充该字段并使用布尔值。

2.5.4 emitsChangedSignal 与 volatile ​

emitsChangedSignal 为必填字段，取值只能为：

"true"
"false"
"const"
"invalidates"

配置非法会影响属性变化通知行为，应按属性真实语义选择合法取值。

volatile 若配置，只能取 true 或 false。volatile=true 表示属性值易变，此类属性变化后不会上报 Redfish ResourceUpdated 事件；若易变属性未正确标记，可能造成上游事件频繁上报。

当 volatile=true 时，通常需要结合业务确认 emitsChangedSignal 是否应配置为 "false"。易变属性频繁发送变化信号可能增加系统性能开销，因此该组合需要按实际业务核查，而不是机械启用广播。

2.5.5 description ​

属性 description 为必填字段，必须是长度不超过 1024 的非空字符串。该字段直接影响业务侧对属性的理解以及资源接口文档生成，应准确描述属性业务含义。

2.5.6 default ​

属性 default 必须与属性定义类型一致，并位于相应类型和校验规则允许的取值范围内。例如 U8 应处于 0～255 范围；字符串默认值长度不大于 64，允许为空串。若属性同时配置了范围、长度、正则或枚举校验，默认值还必须满足相应校验，否则默认值不能正常生效。

2.5.7 数值范围校验 ​

只有数字类型属性可以配置 minimum 和 maximum。适用类型包括 U8、U16、U32、U64、S8、S16、S32、S64。

• minimum 必须落在属性类型自身允许范围内；存在 maximum 时，minimum <= maximum；
• maximum 必须落在属性类型自身允许范围内；存在 minimum 时，maximum >= minimum。

类型不适用、数值越界或上下界关系错误时，范围校验无法正常生效，应删除不适用字段或调整字段值。

2.5.8 字符串长度校验 ​

只有字符串类型属性可以配置 minLength 和 maxLength。规定两者为不小于 0 的整数；同时存在时应满足：

minLength <= maxLength

2.5.9 pattern ​

只有字符串类型属性可以配置 pattern，且其值必须为非空字符串。其它类型不应配置该字段。

2.5.10 enum ​

只有字符串、数字和浮点数类型属性可以配置 enum。enum 必须为数组，数组元素类型与属性类型一致，并满足该类型本身的取值范围。配置在不适用类型上、数组类型错误或元素值越界都会导致枚举校验失效。

2.5.11 校验规则组合 ​

资源属性校验规则分为范围校验、长度校验、正则校验和枚举校验。除长度校验与正则校验允许同时配置外，其它不同类别校验规则不能同时存在。发现冲突时，应保留与业务语义一致的一类校验，删除其它互斥校验规则。

2.6 Method 配置规则 ​

2.6.1 方法名称与描述 ​

资源方法名称必须为长度不大于 64 的非空字符串，采用大驼峰格式，并在当前接口内命名唯一。方法重名会导致后加载定义覆盖前一份定义，应删除或重命名重复方法。

方法 description 为必填字段，必须为长度不超过 1024 的非空字符串。缺少描述或描述过长会影响业务理解及接口文档生成。

2.6.2 请求体参数名称与唯一性 ​

请求体参数名称必须为长度不大于 64 的非空字符串，采用大驼峰格式，并在当前请求体中命名唯一。重名参数可能发生覆盖，应删除或重命名重复参数。

2.6.3 请求体参数 baseType ​

请求体参数的 baseType 为必填字段，类型范围与资源属性一致：支持基础类型、自定义类型以及相应数组类型。缺失或类型非法会导致方法请求参数无法正常管理，应补充或修正类型定义。

2.6.4 请求体参数校验 ​

请求体参数支持以下校验规则：

• minimum：仅数字类型可配置，取值需在类型有效范围内，且不大于 maximum；
• maximum：仅数字类型可配置，取值需在类型有效范围内，且不小于 minimum；
• minLength：仅字符串类型可配置，要求不小于 0，同时不能大于 maxLength；
• maxLength：仅字符串类型可配置，要求不小于 0，同时不能小于 minLength；
• pattern：仅字符串类型可配置，必须为非空字符串；
• enum：仅字符串、数字和浮点数类型可配置，必须为数组，元素类型和值域与参数类型一致。

2.6.5 响应体参数 ​

响应体参数名称必须为长度不大于 64 的非空字符串并采用大驼峰格式；参数在当前响应体中必须命名唯一；baseType 为必填字段并需使用有效基础类型、自定义类型或数组类型。

2.7 Signal 配置规则 ​

资源信号名称必须为长度不大于 64 的非空字符串并采用大驼峰格式，同一接口内信号名称必须唯一。信号重名会发生定义覆盖，应删除或重命名重复信号。

信号 description 为必填字段，必须为长度不超过 1024 的非空字符串。

信号参数名称必须为长度不大于 64 的非空字符串、采用大驼峰格式，并在当前信号参数中命名唯一。信号参数的 baseType 为必填字段，支持基础类型、自定义类型及相应数组类型。

当前规则主要检查信号名称、描述、参数名称、唯一性和 baseType。

2.8 自定义类型使用规则 ​

Interface 中的 defs 可以被属性、方法参数和信号参数引用，但自定义类型之间不能形成循环依赖。需要避免 Struct→Struct、Struct↔Dictionary、Dictionary→Dictionary 等闭环引用，否则会造成资源树接口管理异常。发现循环依赖时，应重新拆分类型关系，使依赖形成无环结构。

接口文件中定义的自定义类型原则上应被当前接口或任意 APP 的私有属性实际引用。若某个类型没有任何引用，应确认是否属于冗余定义；确认无业务用途后应删除，避免长期保留无效模型数据。

3. ObjectPath 配置 ​

以 Demo.json 为例：

{
    "Demo": {
        "path": "/bmc/kepler/Demo",
        "interfaces": [
           "bmc.demo.IDemo",
           "bmc.demo.IDemoUnit.Default"
        ]
    }
}

3.1 配置说明 ​

1. 一个文件只描述一个资源树对象路径。
2. Demo 表示对象路径的名称，采用大驼峰风格，与 model.json 里面的类名没有关联。
3. path 表示在资源树上的对象路径。
4. interfaces 表示此路径下组合了哪些接口，必须是 intf 目录下已经定义的接口。
5. 接口的默认实现（bmc.demo.IDemoUnit.Default）只能被单例的路径组合，即对象路径不能带有实例化对象名作为参数（SystemId/ManagerId 除外）。

3.2 ObjectPath 配置规则 ​

3.2.1 对象名称与唯一性 ​

资源对象名称必须与定义该对象的文件名称一致，为长度不大于 64 的非空字符串，并采用大驼峰格式。名称与文件名不一致、长度超限或命名风格不符合要求时，应统一对象名与文件名并规范命名。

资源对象名称必须全局唯一。不同文件中存在同名资源对象会形成定义冲突，应修改或删除重复定义。

3.2.2 path 格式 ​

资源对象的 path 为必填字段，必须是长度不超过 128 的非空字符串，由若干非空路径段通过 / 拼接，首段必须为 bmc，并允许使用 :x 或 ${x} 表示动态参数。

缺少 path 时资源对象没有实际路径意义；路径格式错误则会增加资源管理和维护成本。发现问题时，应补充 path，并按资源树路径规范调整长度、分段和动态参数写法。

3.2.3 路径唯一性 ​

资源对象路径必须全局唯一，动态参数参与路径唯一性比较，但动态参数名称本身不同不构成新的路径模式。后加载的重复路径可能覆盖先加载路径，导致实际资源对象与预期不一致。

例如：

/bmc/kepler/Systems/${SystemId}/ThresholdSensors/${Id}
/bmc/kepler/Systems/${System}/ThresholdSensors/${SensorId}

若路径结构完全相同，仅变量名称不同，应按同一路径模式处理。发现冲突时，应删除或修改真正重复的路径，而不是仅修改动态参数名称。

3.2.4 接口实现有效性 ​

每个资源对象至少需要实现一个资源接口，且所实现的接口必须已经存在定义。对象没有实现任何接口时不承载实际资源能力；引用不存在的接口时也无法提供预期功能。

因此，发现问题时应补充对象的接口实现关系、补充缺失接口定义，或者删除错误的接口引用。

4. Message 配置 ​

{
    "Description": "This registry defines the oem messages of openUBMC",
    "RegistryPrefix": "openUBMC",
    "RegistryVersion": "1.0.0",
    "Messages": {
        "PropertyValueLengthOutOfRange": {
            "Description": "Indicates that the length of property value is out of range.",
            "Message": "The length of value %1 for the property %2 is out of range. The range of length of value is %3 to %4.",
            "Severity": "Warning",
            "NumberOfArgs": 4,
            "ParamTypes": [
                "string",
                "string",
                "string",
                "string"
            ],
            "Resolution": "Retry using a valid value.",
            "HttpStatusCode": 400,
            "IpmiCompletionCode": "0xC7",
            "SnmpStatusCode": 10,
            "TraceDepth": 0
        }
    }
}

4.1 配置说明 ​

1. Description 表示本消息注册表的说明，可选字段。
2. RegistryPrefix 表示本消息注册表的前缀，必选字段。
3. RegistryVersion 表示本消息注册表的版本，必选字段。
4. Messages 表示消息的集合，必选字段。
5. PropertyValueLengthOutOfRange 表示消息名称，必选字段。
6. Severity 表示消息严重级别，级别有 OK、Warning、Critical，必选字段。
7. TraceDepth 表示消息管理引擎的追踪深度，取值 0-5，0 表示不追踪，可选字段，默认值为 0。
8. HttpStatusCode 表示消息对应的 HTTP 响应码（遵循 HTTP 协议定义的状态码），可选字段，默认值为 400。
9. IpmiCompletionCode 表示消息对应的 IPMI 响应码（遵循 IPMI 规范定义的完成码），可选字段，默认值为 0xFF。
10. SnmpStatusCode 表示消息对应的 SNMP 错误码，可选字段，默认值为 5。
11. Message 表示消息的描述，必选字段，支持动态参数，参数用 %1、%2... 表示。
12. NumberOfArgs 和 ParamTypes 分别表示描述中动态参数个数和每个动态参数的类型，类型包括 string、integer、number。
13. Resolution 表示消息的处理建议，可选字段。

5. 资源协作接口开发规范 ​

5.1 资源树命名要求 ​

服务命名 ​

• 服务 Service 采用 “域名表示法”：bmc.kepler.<app_name>，其中 <app_name> 采用 unix_like 风格，并且与 APP 名称保持一致。
• 此服务表示在总线上提供 IPC API 的进程，如：bmc.kepler.fructrl，表示组件 fructrl 提供的 API 接口。
• 示例：

bmc.kepler.fructrl
bmc.kepler.key_mgmt
bmc.kepler.bios

对象命名 ​

• 对象 Object 采用 “文件系统目录法”，比如 /bmc/kepler/[资源分类]/:Id/[资源子分类]/[资源子子分类]，其中 “资源分类及其子分类” 统一采用大驼峰命名风格。
• Object 类似 C 指针，引用 C 对象，采用文件系统路径方式以便于理解，开发人员按照目录划分资源树。
• 对象 Object 按照资源分类命名，与 APP 名称无关。

接口命名 ​

• 接口 Interface 是信号、方法、属性的集合，表示某一类资源操作的集合体，也就是 “类” 的定义，开发人员负责接口的实现，如 bmc.kepler.Systems.Power，表示系统电源接口集合。
• 接口 Interface 按照资源分类命名，与 APP 名称无关。

方法命名 ​

• 方法 Method 的方法名、参数遵循 “大驼峰命名语法”，接口可以包含方法（函数）。

信号命名 ​

• 信号 Signal：类似方法，使用场景：用于对等体的一般通知，总线广播。一般情况下，方法是“双工，一对一通信”，信号是“单工，一对多通信”。

属性命名 ​

• 属性 Property：对象公开的变量，可以由客户端读取或修改。

签名命名 ​

• 签名 Signature：“方法、信号、属性” 接受或返回的一组参数。

集合资源路径命名 ​

• 资源路径中 /bmc/kepler/Chassis/:ChassisId、/bmc/kepler/Systems/:SystemId、/bmc/kepler/Managers/:ManagerId，变量名称固定使用 ChassisId、SystemId、ManagerId，作为资源树和自发现的接口。
• 只要是组件内使用的 Id，简化为 Id。
• 示例：

/bmc/kepler/Chassis/:ChassisId
/bmc/kepler/Systems/:SystemId/Bios
/bmc/kepler/Managers/:ManagerId/SOL
/bmc/kepler/TaskService/Tasks/:Id

5.2 资源树属性（Property）及方法（Method）定义 ​

属性变化信号 ​

属性变化默认会发送 signal，属性定义时，按需配置是否广播（emitsChangedSignal 配置为 false/const 都不会发送广播）。

属性取值范围 ​

• mdb_interface 代码仓对属性的取值范围要明确。非 bool 类的整数属性、参数要用枚举类型定义，尤其是 enum、array 类型使用 $ref 定义取值。

通用方法定义 ​

通用方法定义，需要考虑“签名”稳定性、扩展性，推荐用 a{ss}。

敏感信息查询 ​

• 敏感信息（例如加密后的明文数据）需要做成 method 查询，不能以 property 直接暴露。

访问权限配置 ​

资源树属性及方法需要配置对应的访问权限。

5.3 资源树信息范围 ​

资源树接口定义 ​

资源树接口定义，需要保证接口的清晰、稳定、兼容。

资源树数据范围 ​

只将对外暴露的数据定义在资源树上，内部逻辑处理的中间数据本地程序管理。

5.4 组件依赖关系 ​

组件依赖接口 ​

组件统一依赖接口，资源树定义接口。

MDS 依赖声明 ​

在 MDS 中列出组件所依赖的所有接口 Interface。

资源树依赖方向 ​

资源树为偏序依赖，上层服务能访问本层及较下层的资源数据，不能反过来依赖。

6. 配置检查与跨模型一致性 ​

6.1 Interface 与资源对象一致性 ​

资源接口至少要被一个资源对象实现。如果接口未被任何 ObjectPath 实现，应确认是否遗漏资源对象配置，或者该接口是否已经成为冗余定义。

未被实现的接口不会形成实际资源能力。若接口应继续使用，应补充至少一个资源对象对该接口的实现；若确认接口无业务用途，应删除冗余接口。

Interface
    ↓ 至少被一个资源对象实现
ObjectPath

6.2 资源对象与 MDS 一致性 ​

资源对象只有在 APP 的 MDS 中被管理，资源树定义的功能才能生效。版本中可能包含资源树全集对象，因此某些当前产品不涉及的对象未被 MDS 管理可能属于正常情况；如果当前产品需要该资源能力，则必须补充对应 MDS 管理关系。

资源对象未被需要的 MDS 管理时，BMC 会缺失相应软件管理功能。处理时应结合产品实际判断：需要该功能则补充 MDS 管理，不涉及该功能则可忽略该提示。

Interface
    ↓
ObjectPath
    ↓ 由 MDS 管理
APP / Component

6.3 资源对象管理唯一性 ​

同一个资源对象最多只能由一个 MDS 管理。多个 APP 同时管理同一资源对象会使同一软件功能被多个模块实现和管理，导致功能边界和资源归属混乱。

发现重复管理关系时，应确定唯一责任组件，删除其它 APP 对该资源对象的管理定义。

6.4 定义文件格式 ​

资源接口和资源对象定义文件必须是合法 JSON 文件。文件格式错误会导致资源接口或资源对象无法加载并引起对应业务异常，因此在检查具体字段之前应先保证 JSON 格式正确。

6.5 建议检查顺序 ​

完成配置后建议按以下顺序进行自检：

1. 检查资源接口和资源对象定义文件是否为合法 JSON。
2. 检查 Interface 名称、全局唯一性以及是否至少包含属性、方法或信号。
3. 检查属性名称、接口内唯一性、baseType、readOnly、emitsChangedSignal、volatile、description 和 default。
4. 检查属性的范围、长度、正则和枚举校验是否用于正确数据类型，并检查校验规则组合是否冲突。
5. 检查方法名称、接口内唯一性和描述。
6. 检查方法请求体参数名称、唯一性、类型和校验规则。
7. 检查方法响应体参数名称、唯一性和 baseType。
8. 检查信号名称、唯一性、描述及信号参数名称、唯一性和 baseType。
9. 检查自定义类型之间是否存在循环依赖，并清理未被引用的冗余类型。
10. 检查 ObjectPath 对象名称、全局唯一性、path 格式和动态路径唯一性。
11. 检查每个资源对象是否至少实现一个已经定义的 Interface。
12. 检查每个有效 Interface 是否至少被一个资源对象实现。
13. 检查当前产品需要使用的资源对象是否已经由对应 APP 的 MDS 管理。
14. 检查是否存在多个 MDS 同时管理同一个资源对象。

7. 参考规则 ​