BMC Hardware API Abstraction for Scalable Chipset Support

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Existing BMC implementations face scalability issues due to hardware-specific code requirements for each device type, making updates and porting new chipsets cumbersome, and the Entity Manager service is not easily scalable, necessitating frequent application updates.

Innovation Solution

A hardware API service is introduced to abstract hardware access in BMCs, allowing updates to be applied to the API without modifying applications, enabling seamless integration of new hardware and firmware components.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If hardware-specific code is implemented for each device type in BMC, then hardware compatibility is achieved, but scalability and ease of updating are deteriorated

Engineering Contradiction:

Improvehardware compatibilityVSAvoidcode maintenance complexity

Core Design Contradiction:

Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent introduces an intermediary layer (abstraction layer) between the application code and hardware devices. This intermediary translates generic API calls into hardware-specific operations, allowing the BMC to support multiple device types without requiring hardware-specific code in applications. The intermediary handles the complexity of hardware variations while presenting a unified interface to applications.

Inventive Principle:

Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent segments the BMC code into distinct layers: a generic application layer that interacts with hardware through standardized APIs, and a hardware-specific layer that handles device-specific implementations. This segmentation allows independent updates of hardware components without affecting applications, resolving the contradiction between hardware compatibility and code maintenance complexity.

Inventive Principle:

Principle #1Segmentation

2Adaptability or versatility

If the Entity Manager service is updated to support new chipsets, then hardware support is improved, but application stability is worsened due to frequent updates

Engineering Contradiction:

Improvehardware supportVSAvoidapplication stability

Core Design Contradiction:

Adaptability or versatilityVSReliability

Solution Approach 1:

The abstraction layer serves as a stable intermediary that shields applications from hardware changes. When new chipsets are added, only the hardware-specific layer needs updating, while the generic API layer remains unchanged. This ensures application stability while improving hardware support capabilities.

Inventive Principle:

Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent establishes a preliminary standardized interface (API layer) that defines how applications will interact with hardware. This preliminary action creates a stable contract between applications and hardware, allowing hardware to be updated without breaking the application layer, thus maintaining reliability while enabling adaptability.

Inventive Principle:

Principle #10Preliminary action

3Adaptability or versatility

If BMC hardware is scaled to support more devices, then functionality is improved, but system downtime increases due to reboot requirements

Engineering Contradiction:

Improvehardware scalabilityVSAvoidsystem downtime

Core Design Contradiction:

Adaptability or versatilityVSLoss of time

Solution Approach 1:

The patent segments hardware configuration into modular device profiles that can be loaded dynamically. New hardware can be added by loading new device profiles without requiring a system reboot, enabling hardware scaling while minimizing downtime. The segmented architecture allows hot-swapping of hardware configurations.

Inventive Principle:

Principle #1Segmentation

4Ease of operation

If hardware access is abstracted through a standardized API, then ease of operation is improved, but hardware-specific functionality may be lost

Engineering Contradiction:

ImproveAPI usabilityVSAvoidhardware-specific functionality

Core Design Contradiction:

Ease of operationVSAdaptability or versatility

Solution Approach 1:

The abstraction layer is designed as an intelligent intermediary that preserves hardware-specific functionality through the standardized API. It translates generic API calls into hardware-specific operations while maintaining access to device-specific capabilities. This allows ease of operation through standardized interfaces while retaining full hardware-specific functionality through the mediation layer.

Inventive Principle:

Principle #24Intermediary (Mediator)

Data Source

PatentUS12423204B2Systems and methods to abstract hardware access in baseboard management controllers (BMCS)

Publication Date: 2025.09.23 DELL PROD LP

AI summary

Embodiments of the present disclosure provide a system and method to abstract hardware access from applications running on a Baseboard Management Controller (BMC) using a hardware API service. According to one embodiment, an Information Handling System (IHS) includes executable instructions to expose an Application Program Interface (API) including a plurality of labels each uniquely identifying one of the hardware devices and a function to be provided by the one hardware device, and when an application executed on the BMC calls one of the labels, communicate with at least the one hardware device to perform the function specified by the one label.