openUBMC拥有一个灵活的生态系统，可以让平台开发者、开源社区开发者、独立特性开发者、产品开发者、硬件厂商等轻松地对组件进行剪裁与新增。同时，openUBMC提供统一工程工具、工程约束和最佳实践能力，通过一站式开发平台极大降低了组件化开发的边际成本。
openUBMC的核心特性包括：
组件化：openUBMC引入Conan包管理器，采用组件化可伸缩架构的设计，将每个功能都作为一个独立的组件进行开发。这种设计允许用户进行源码修改、整体新增组件，以及灵活选择组件，并支持组件独立构建和发布，以适应不同的开发场景和需求，为应用市场提供基础。简而言之，组件化的特性使openUBMC具有以下优势：
- 灵活扩展和定制：支持多方共建和共享组件，构筑组件应用市场和代码托管仓。开发者可以在不改变原有代码的情况下，通过添加新的组件或插件来增加新功能或新特性。
- 按需裁剪：允许用户根据自己的产品需求来选择性地保留或移除某些功能。这意味着用户可以只保留需要的功能，让产品更加精简和高效。
一站式独立开发平台：openUBMC提供可靠的软件工程能力。通过标准化接口设计、编码、代码生成、编译、测试、发布等过程，使所有组件共享相同的CLI命令，实现组件独立构建、测试和发布。一站式独立开发平台的特性主要表现在以下方面：
- 一站式命令行工具：openUBMC提供了一整套的开发工具，从定制、开发、编译到调试，一应俱全，极大简化了开发流程。
- 代码自动生成：openUBMC根据机制与策略分离的设计模式，采用模型驱动开发，通过业务建模，实现接口代码的自动生成。支持组件灵活发布和极简的引用流程；支持硬件组装、特性组件、产品级构建和验证。
通过openUBMC，开发者可以更快地构建和发布自己的产品，同时也为用户提供了更多的个性化选择。这是一个为创新和效率而生的平台。
组件化
openUBMC通过组件化的方式实现一个个相对独立且能够自我迭代的功能，再由这一个个独立的组件合并成一个庞大的系统。这种方式支持各组件独立设计、编码、构建、验证、发布，可以让系统内部的功能交互更清晰，同时能更好地支持定制化与裁剪，以满足不同客户与伙伴的诉求。
在代码实现上，openUBMC采用了机制与策略分类的模式，通过提取组件之间的共性功能建立公共机制，各个组件只需在机制基础上，借助于某些参数和算法来实现该功能的优化，或达到不同的功能目标。这种模式使组件开发人员主要围绕内存对象编写业务逻辑代码。接口定义、组件构建等内容使用公共机制进行开发。openUBMC中的公共机制包括：
- 统一格式的组件模型定义源文件MDS。MDS对组件构建策略、管理的数据、IPMI，以及组件的扩展和定制能力进行建模，其设计目标是整个系统以及开发工具具有相同的模型基础。工程工具基于模型源文件MDS自动生成相关的配置文件和代码，以减少重复劳动，让开发人员聚焦业务代码。具体的MDS定义方式参考《MDS》。
- 硬件自发现CSR和PSR设计。openUBMC使用CSR和PSR文件定义硬件自描述信息，实现软件与硬件解耦。其中，CSR是站在软件的角度来定义硬件的，使用软件的语言描述硬件“是什么，有什么，能做什么”，其体现的主要是硬件内部的器件信息、器件互联关系、器件的能力等。PSR是站在软件的角度来定义整机硬件“是什么，有什么，能做什么”，其体现的主要是整机视角看到的硬件组成结构，配置合法性检查规则等。具体的CSR和PSR定义方式参考《硬件自描述文件(CSR)》。
- 错误引擎机制。在openUBMC中，各组件的错误定义以统一的格式由
mdb_interface组件仓统一管理，各组件只需自动动态将错误信息注册到错误引擎，后续由错误引擎框架接管各组件的错误处理流程。错误引擎机制的使用参考错误引擎。 - 统一的开发者测试（DT）架构。每个组件在实现业务码的同时需要完成DT代码，用于维护代码质量。openUBMC将开发者测试分为单元测试和集成测试。单元测试关注于功能函数的测试，使用
BMC Studio CLI的bingo test -ut命令执行；集成测试关注于组件间接口调用的测试，使用bingo test -it命令执行。测试代码的编写可参考《组件的独立测试》。 - 构建系统统一维护组件构建、测试、发布依赖的公共工具集（如编译器、Conan等），并为所有组件提供统一的CLI命令。如上述组件测试命令
bingo test；自动构建出包命令bingo build，该命令默认将生成的Conan包存放在root/.conan/data目录下；自动生成代码命令bingo gen，该命令会根据组件模型定义源文件MDS在组件gen目录下生成新的文件。组件构建命令的使用请参考《组件的构建与发布》。
独立编码
openUBMC对外的接口由资源协作接口定义，组件是openUBMC的全量功能提供者，实现资源协作接口。
openUBMC中，一个组件对应一个代码仓，对外暴露一套服务接口。每个组件对外的接口采用D-Bus接口设计方式，即一个对象路径（ObjectPath）是组件管理的一个对象实例，一个接口（Interface）是多个属性、方法、信号的组合，对象实例可以组合实现多个不同的接口，所有组件的接口合在一起组成了openUBMC的管理数据模型（MDB）。每个组件的接口和对象路径的关系统一规范，将其称之为资源协作接口。资源协作接口的介绍可参考《资源协作接口--D-Bus》。
简而言之，openUBMC通过资源协作接口定义接口规范。组件是openUBMC的全量功能提供者，将接口与实现分离。面向开发系统，各个组件将数据与接口都通过资源协作接口呈现，各组件开发者只需关注资源协作接口上有什么可用的数据与接口，无需关注提供方，从而实现组件与组件的解耦，降低组件协作成本。资源协作接口的使用为openUBMC带来了以下好处：
- 接口统一定义，资源协作接口定义了接口，组件实现接口具体的业务，接口更加规范。
- 支持跨语言编程，各组件开发者都基于资源协作接口进行交互，不关注具体的实现语言。
- 依赖统一管理，各组件进行开发时，面向接口编程，依赖接口，不依赖具体服务。
- 通信管理，基于D-Bus封装的套接字协议通信，具备开放性，并实现组件之间低延迟、低开销、高可用性的通信要求。
除此之外，在组件开发过程中，openUBMC引入了Skynet作为开发框架，降低了编码的复杂度，提高生产效率。Skynet框架实现了轻量级服务的概念，将不同的业务逻辑放置在独立的执行环境中进行处理，以实现协同工作。该框架采用基于消息驱动的多线程调度模型，最大化地利用多核CPU的性能。为了进一步简化业务逻辑的编写，Skynet还集成了Lua脚本引擎，利用沙盒来隔离不同服务的执行环境。这种设计不仅提高了代码的模块化和可维护性，还确保了系统的高性能和稳定性。Skynet的使用介绍参考《Skynet开发指南》。
openUBMC大规模组件化让组件配套关系极为复杂，组件质量看护也是一个挑战，当前应对措施主要是落地组件开发者测试。开发者在进行业务代码开发的同时，需要配套充分的开发者测试（DT），以保证业务代码质量，避免代码缺陷。DT代码为业务代码的一部分，与被测业务代码同仓管理。详细测试代码编写请参考《组件的独立测试》。
独立构建
组件的独立性不仅表现于独立开发，openUBMC使用Conan与CMake集成的方式同时支持组件间独立构建、打包和发布。
Conan是一个开源的C++包管理器，它能够在多种操作系统上处理库的依赖问题。Conan的出现极大地简化了库的安装、集成和版本控制流程。借助Conan，开发者可以避免所谓的“依赖地狱”，即项目中库之间的版本冲突问题。
CMake是一个开源的跨平台自动化构建系统，它使用配置文件（CMakeLists.txt）来指导编译过程。与传统的Makefile相比，CMake的配置方式更为简洁明了，且能够自动适配不同的编译环境，从而生成相应的Makefile或项目文件。
在openUBMC中，开发工具BMC Studio集成这两个工具，为openUBMC的组件开发提供了一个强大的构建和依赖管理环境，和统一的BMC Studio CLI命令行工具。各组件已实现初始化的相关构建代码，开发者无需修改Conan以及Cmake相关文件，便可直接通过BMC Studio CLI命令行工具实现构建、测试等。如开发者需定制化构建、出包等过程，可参考《组件的构建与发布》。修改相关文件内容。
一站式独立开发平台
BMC Studio的命令行工具BMC Studio CLI承载了工程工具、工程约束和最佳实践，提供一站式命令行工具，规范组件开发和产品集成行为，降低组件开发边际成本。bingo工程工具通过标准化接口设计、编码和代码生成、编译、开发者测试、组件发布等过程，使所有组件共享相同的CLI命令，实现组件独立设计、编码、构建、测试和发布。构建命令请参考《BMC Studio CLI (bingo)》。