OCP RAS API: A common framework for datacenter RAS, showcased on Arm

This blog was co-authored by Jose Marinho, Arm and Drew Walton, Microsoft.

---

From server-level RAS to rack-scale fault management

At data center scale, reliable operation is fundamental. Cloud hardware fleets need to deliver correct results, meet service level agreements, and keep ownership costs under control—even when hardware unexpectedly fails. That is the mission of Reliability, Availability, and Serviceability (RAS).

RAS reaches far beyond fault management, even though the two are often treated as interchangeable. Fault management is a critical pillar of RAS: detecting and logging errors, uncovering their root causes, and planning effective actions to remove faults.

The OCP RAS API defines a standard framework for fault management, helping turn “something went wrong” into a clear understanding of what happened, why, and what to do next. Hyperscalers, silicon providers, and system vendors come together in the latest Version 0.9 Specification of the OCP RAS API Workstream to define a common approach to hardware fault management framework. Contributors including Arm and Microsoft collaborate on the definition of vendor-agnostic interfaces that connect hardware-specific RAS capabilities with rack- and data-center-level management.

Hardware errors originate inside individual components, but their operational impact is much broader. A correctable memory error may initially affect only one DIMM. A persistent fault may later require memory-page retirement, row repair, workload migration or maintenance scheduling. Multiple apparently unrelated events across a rack may indicate a shared power, thermal, or cooling issue. At data-center scale, the decision is no longer only whether a component has failed. The operator needs to know:

• Whether the fault is isolated or part of a wider pattern. 
• Whether the server can remain in service.  
• Whether workloads should be moved.  
• Whether remediation can be performed online.  
• Whether maintenance should be coordinated across a rack.  
• Whether similar systems elsewhere in the fleet are at risk. 

A common RAS control plane for heterogeneous racks

Data centers are intentionally heterogeneous. Operators may deploy servers from several system vendors and use silicon from multiple processor architectures, memory, accelerators, and networking suppliers.

Without a commonality on some plane, heterogeneity creates unbearable integration costs. Every vendor-specific management model has to be integrated into the operator’s monitoring, incident-management, and automation systems. Operators have to custom-build software and policies for controlling new RAS features, slowing the adoption of these new features.

The OCP RAS API changes the integration boundary. Instead of requiring the data-center control plane to understand the internal RAS implementation of every product, each silicon part, and platform in general, presents a consistent external model. The common model covers capabilities such as:

• RAS endpoint discovery.
• Endpoint and platform identity.
• Severity-based event queues.
• Common Platform Error Record (CPER) collection.
• Event notification.
• Common Platform Action Descriptors (CPADs) for automating RAS Actions.
  • Standard action request data model, with vendor-specific payloads, where vendor innovation and differentiation is desirable.
• Standard interface for initiating RAS actions
  • Decouples the action data model from the action request interface, the latter is entirely vendor-agnostic.
• Operator visibility into and control of RAS actions.
• RAS Action completion reporting.
• Gives visibility to the data center operation on actions proposed by the vendor and which actions are allowed by the system.
• Mapping the RAS API protocol constructs to standard management transports such as PLDM and Redfish.

The datacenter operator builds rack-level services against the common RAS API rather than against each individual server and device implementation.

The OCP RAS API extends and builds on top of other OCP efforts, like the OCP SBMR specification which establishes a common foundation for management interoperability. The OCP SBMR covers the base interfaces and protocols to enable the use-cases expected in modern datacenter fleets. The OCP RAS API builds on top of that rich and stable substrate to define the protocol layer for RAS user-cases.

A new platform still requires qualification, but onboarding does not necessitate a completely new fault-management stack. The same collection, policy, storage, and orchestration infrastructure can be reused. Platform-specific knowledge can be introduced through focused components, such as vendor analyzers, instead of being embedded throughout the data-center software environment.

OCP RAS API: an open forum for rack-scale RAS enablement

Today, the landscape for error logging and action request is highly fragmented, with an established model where vendor- and platform-specific abstraction between hardware and management software are prevalent.

At the root, the RAS API effort works to remove that fragmentation.

The latest framework definition is captured in the OCP RAS API 0.95rc1 WIP release.

OCP RAS API design

The architecture defines two complementary frameworks:

• An error-logging framework through which RAS endpoints publish rich hardware error information using Common Platform Error Records, or CPERs.
• A RAS action-request framework through which analysis software can describe proposed mitigation, diagnostic or repair operations using Common Platform Action Descriptors, or CPADs.

A CPER carries evidence from the platform toward the management layer. A CPAD carries an action request back toward the appropriate platform endpoint.

The RAS API OCP workstream’s goal is to standardize the interface, not the implementation. Hardware vendors remain free to differentiate through better fault detection, richer telemetry, more accurate analysis, predictive capabilities, stronger containment, and less disruptive repair mechanisms. Those are meaningful product capabilities. What no longer needs to be differentiated is the basic plumbing required to discover an endpoint, collect an error, route it for analysis, request an action, and observe the result.

The Framework architecture defines the following entities and roles:

• RAS API Initiator: retrieves error records and forwards action requests to the target entity.
• RAS API Endpoint: generates CPER error records and makes these available to the RAS API Initiator. Receives CPAD action requests from the RAS API Initiator and coordinates with other entities in the server to perform those actions. A RAS API Endpoint is expected to be associated to a silicon system component.

Additionally, the framework assumes elements of the datacenter infrastructure, like the error analyzer. This entity is intended to review all error records from a server or at the rack-level, diagnose faults and issue action requests to deal with those.

The RAS API defines a coordinate system to identify the RAS API Endpoint (as the target of CPAD action requests), and the Analyzer that is tasked with analyzing the error records.

These coordinates are embedded on the CPAD and CPER records to enable their routing across the datacenter infrastructure to and from the server.

RAS API bindings

The OCP RAS API defines the high-level interactions between a RAS API Endpoints and a RAS API Initiator. To be implemented, these interactions are mapped to the communication layer existing between those entities.

Mappings can be created ad-hoc, by each OEM or server vendor, but standardizing the mapping to common communication layers promotes interoperability and code reuse, and overall platform development investment.

DMTF PMCI is working on standard mappings of RAS API to PLDM, as evidenced by:

• DMTF RAS API mapping to PLDM requirements WIP
• DSP2094 DMTF RAS API PLDM Modeling WIP

Having PLDM mappings will usher wide deployment of the OCP RAS API framework and enable robust, battle tested, and widely maintained implementations on the BMC side, as well as tooling and libraries to enable the SoC-side functionality. Microsoft has a proposed Redfish binding for DMTF that is included in the demo described in the next section.

RAS API proof-of-concept demo

To prove the framework's feasibility, completeness and interoperability strength, companies collaborated to create an end-to-end, proof-of-concept demo encompassing most of the relevant use-cases.

Components developed from different companies are showcased interacting at from levels of the framework. The demo illustrates the high level of interoperability enabled by the framework. Microsoft developed a proof-of-concept, shown in the figure below, that uses the proposed Redfish RAS API mappings in a representative data center control plane to collect errors, analyze them, apply policies to proposed actions and deliver CPADs to RAS API endpoints. The RAS API Initiator in the Microsoft demo is shown obtaining error records from two servers. Those servers, in separate parts of the demo, are:

1. An Arm Neoverse RDV3R1 proof-of-concept with a complete BMC emulation on an Arm FVP model.
2. A Microsoft sample BMC implementation, emulated as a Redfish mockup server

At a high level, the demo shows the data center fault management pipelines interacting with RAS API endpoints and error analyzers. The BMC implements the vendor-agnostic Redfish RAS API schema thus enabling a wholly standard flow.

The Arm server emulation takes the flow to whole end-to-end depth, connecting the RAS Analyzer ultimately to the RAS API endpoint deep within the Arm Host SoC.

Demo flows

The flows showcased CPER memory errors being generated on the servers and flowing to the Analyzer. As the Analyzer gathers increasing error evidence, it is shown reasoning the time-series, to further refine its fault diagnosis.

As a last proof of interoperability, a memory vendor analyzer plugin is shown seamlessly integrating with the Microsoft built error analyzer. A separate flow shows an error being injected (through a CPAD record) on the Microsoft server.

Visit us at OCP Summit 2026 to learn more

To learn more about this architecture and see a demo of the Arm and Microsoft prototypes, visit the Arm and Microsoft booths at the 2026 OCP Global Summit, San Jose, CA, Oct 12-15, 2026. 

The demo and aspects of the OCP RAS API design will be presented at the 2026 OCP Global Summit.

OCP Hardware Fault Management Workstreams Status and Relationship  OCP RAS API PLDM Modeling

References 

• OCP RAS API v0.95.rc1WIP
• OCP RAS API wiki link
• OpenBMC proof-of-concept on the Arm Neoverse FVP platform
• OCP SBMR wiki link on github
• Arm Server Base Manageability Requirements (SBMR) Specification
• Advancing server manageability on Arm Neoverse Compute Subsystem (CSS) with OpenBMC
• DMTF RAS API mapping to PLDM requirements WIP
• DSP2094 DMTF RAS API PLDM Modeling WIP

 

Demo source code

• https://github.com/KrishnaAnnam/redfish-dev-server/tree/main/examples/ras_api_demo
• Microsoft/redfish-dev-server: BMC Redfish Simulator 
• https://gitlab.arm.com/server_management/PoCs/fvp-poc