OCPP 2.1 — Certification Profiles Summary (Part 5)

Purpose: Orientation for AI agents and developers on the OCPP 2.1 certification program — what certification profiles are, the profiles defined in Part 5, which functional blocks (A–S) and use cases each profile bundles, the mandatory controller components per profile, and how the new 2.1 functionality (DER control, V2X / bidirectional power transfer, tariff/payment, battery swapping) maps to certification.

Last updated: 2026-06-12

NON-NORMATIVE SUMMARY. This document is an original, paraphrased overview of OCPP 2.1 Part 5 (Certification Profiles). It is not the certification specification and is not authoritative for any certification decision. The OCA (Open Charge Alliance) certification program — its Part 5 document, the Part 6 test cases, the OCA Compliance Testing Tool, and the OCA-accredited test labs — are the only authoritative sources. Always confirm the current profiles, features, and requirements against the official OCA artifacts and your accredited test lab before relying on anything here. Do not treat this file as a Protocol Implementation Conformance Statement (PICS).

#How This Document Was Produced

This document's dominant confidence tier is spec-knowledge — an original summary of the OCPP 2.1 Edition 2 Part 5 "Certification Profiles" specification (Edition 2, 2025-12-03, 68 pp). Profile names, the feature lists per profile, the feature→use-case mapping, and the mandatory-controller-component lists are all paraphrased and restructured from Part 5; no spec prose is reproduced verbatim (the OCA specification is CC BY-ND licensed). The A–S functional-block taxonomy used in the matrix below is cross-referenced against the mechanically generated Use-Case Catalog and the schema block docs.

Mapping basis (important). Part 5 does not organize requirements by the A–S functional-block letters. It organizes them by certification profile and by optional feature ID (e.g. C-01, SC-8, BPT-1). Part 5 Appendix C ("Features vs. OCPP use cases") maps each feature ID to the Part 2 use-case IDs it touches (e.g. feature C-30 → use case C01). Those use-case IDs carry the A–S block letter as their prefix (use cases A01…A05 = block A, C01…C25 = block C, and so on). This document therefore derives the profile → A–S block mapping transitively: profile → feature IDs / described functionality → use-case IDs (from Appendix C and the profile tables) → A–S block. Where a profile's functionality is described only in prose (Part 5 Table 1) rather than via a feature ID, the block assignment is inferred from the matching use-case names and is noted as such. This is a non-normative interpretation; the authoritative artifact is the per-test-case condition column in Part 5 Chapter 4.

This document contains 2 escalation points marked with > **ESCALATE:**. When an AI agent encounters one, it MUST stop and ask the developer / product owner to make the decision — certification scope is a business and deployment decision, not a code decision. See METHODOLOGY.md for the full confidence and escalation model.

Companion documents:

• OCPP 2.1 Overview & Migration Guide — what is new in 2.1 and how the docs fit together
• Use-Case Catalog (Part 2) — the A–S blocks and every use case the profiles reference
• DER Control Deep-Dive — block R, certified by the DER control profile
• Bidirectional Power Transfer (V2X) Deep-Dive — block Q, certified by the Bidirectional Power Transfer profile
• Schema block references (field-level messages): Security, Provisioning, Authorization, Transactions, Smart Charging, Bidirectional, DER Control, Certificates, Tariff & Cost
• Device Model Reference — the controller components that must exist for a profile to be testable

#1. What Certification Profiles Are

OCPP supports everything from a simple AC home charger to a megawatt DC charger, so requiring every vendor to implement and pass every OCPP feature would be pointless. The OCA certification program therefore bundles functionality into certification profiles: a profile is a named set of OCPP functionality that a charging station or CSMS can be certified against. A vendor certifies for the profiles relevant to its product, not necessarily for all OCPP functionality.

Key facts (paraphrased from Part 5):

ESCALATE: POLICY-DEPENDENT — Which profiles to certify for (and which optional features to implement within them) is a product, market, and commercial decision. Do not infer it from the code. Confirm the target profile set with the product owner and the chosen OCA test lab.

#2. The Profiles Defined in Part 5

These are the actual profile names from Part 5 Table 1 (Certification profiles) and Chapter 5 (mandatory controller components). Do not invent others.

Notes:

• Payment (2.1) appears in Part 5 as a sub-section within the Core profile (set default tariff, local cost calculation, prepaid card, integrated/standalone payment terminal, settlement, QR codes), and it has its own mandatory controller components (Core: P-0 (2.1)). It is not a separate top-level profile; treat it as an optional Core feature group certified via the P-* feature IDs.
• Battery Swapping is not a standalone certification profile. It is handled as a product subtype of a charging station: the BatterySwapCtrlr component is mandatory in Core only for the Battery Swapping Charging Station subtype, and CSMS feature C-76 (2.1) ("Support for Battery Swapping Stations") is optional. See §4.

#3. Profile × Functional-Block / Use-Case Matrix

This table maps each certification profile to the A–S functional blocks of the Use-Case Catalog. Legend: R = block is core to (required scope of) the profile; O = block is touched only through optional features within the profile; · = not applicable.

The mapping basis is the transitive derivation described in How This Document Was Produced (profile → feature/described functionality → Part 2 use-case IDs → A–S block). For block letters whose membership is described only in profile prose, the assignment is from matching use-case names.

Reading notes:

• Core is broad because Part 5 places the bulk of OCPP functionality in it (auth, provisioning, transactions, remote control, availability, metering, firmware, certificate install/retrieve, diagnostics/customer-info) plus optional Core sub-areas (D Local Auth List, H Reservation, blocks I (Tariff And Cost) and O (Display Message), P data transfer, S battery swapping for the battery-swap subtype).
• Adv. Security is narrow: it sits on top of Core's certificate/security functionality (blocks A and M) — client-side cert, update CS cert, security-profile upgrade.
• ISO 15118 support spans authorization (C, incl. PnC contract certs and EIM), smart charging (K/F), certificate management (M), and signed meter values (J); its dependency on Advanced Security and Smart Charging is why those blocks appear under it as well. Block A (Security/TLS use cases A01–A05) is reachable via the Advanced Security dependency, hence A = O. Block E is O because ISO 15118 charging happens within a transaction, so transaction-event use cases (block E) are exercised during ISO 15118 sessions.
• Smart Charging EMS-control sub-area reaches into V2X (block Q) via external V2X control features (SC-10), hence the O there. Block E is O because remote start with a charging profile — and profile application during an active transaction — exercises transaction-event use cases (block E).
• Bidirectional Power Transfer is block Q; it requires Smart Charging (K) and uses authorization (C) for V2X authorization over ISO 15118-20.
• DER control is block R; in practice it is exercised alongside V2X sessions (block Q) and smart-charging setpoints (block K), hence the O marks there. Block E is O because DER/V2X control operates within an active transaction, so block E use cases are exercised alongside Q and K.

#3.1 Feature → use-case anchors (selected, from Part 5 Appendix C)

These are representative feature IDs and the Part 2 use cases they map to, illustrating the derivation. Full lists are in Part 5 Tables 2, 3 and Appendix C.

DER control has no optional features on either side (Charging Station and CSMS tables both state "No optional features for this profile"); all its test cases are Mandatory or Conditional on hardware/ISO features once you certify for the profile. Advanced Security has no optional features on the CSMS side, but the Charging Station side lists optional features AS-2, AS-3, AS-4, AS-4.1, and AS-4.2 in Part 5 Table 2.

#4. New 2.1 Functionality and How It Maps to Certification

OCPP 2.1 introduces functionality that Part 5 wires into certification as follows:

ESCALATE: POLICY-DEPENDENT — Whether to pursue the new 2.1 profiles (DER control, Bidirectional Power Transfer) or the Payment/battery-swap feature groups is a deployment and grid/utility decision (and for V2X depends on certifying Smart Charging first). Confirm scope with the product owner and grid/utility stakeholder.

#5. Mandatory Controller Components per Profile

A functional area cannot be tested without the device-model controller component that holds its variables, so Part 5 Chapter 5 makes specific components mandatory for certification. (Component details: Device Model Reference.)

#6. How the Test Tables Work (Part 5 Chapter 4)

For orientation only — these are not reproduced here. Each test case row in Part 5 Chapter 4 carries:

The Part 5 test sections are: Core (4.2), Advanced Security (4.3), Smart Charging (4.4), ISO 15118 Support (4.5), Bidirectional Power Transfer 2.1 (4.6), DER Control 2.1 (4.7). The Part 6 document holds the full test-case bodies; the OCA Compliance Testing Tool executes them. For the authoritative M/C status of any specific test case, consult Part 5 and Part 6 directly.

#7. Quick Reference