Vector DERMS vs OSCP 2.0 Integration Deltas¶

Short summary of integration-specific behaviors where Vector DERMS differs from the OSCP 2.0 specification.

Authentication and Onboarding¶

Uses OAuth client credentials plus static headers (fp-id, apikey, x-request-id, and x-access-token in test) instead of the OSCP Register token exchange. OAuth token URLs are environment-specific.
Charge Operator provides OSCP base URL, token URL, client credentials, static headers, and site asset/group IDs to Vector. Vector reciprocates with its OSCP base URL, token URL, and credentials. Register message flow is not used.

update_asset_measurements: Vector expects Charge Operator → Vector (acting as CP) with all charging activity aggregated into a single “asset” per group. OSCP defines FP → CO; adjust roles/direction accordingly.
update_group_measurements: Not supported by Vector. All metering must be sent via update_asset_measurements after aggregation.
Handshake initiation is bidirectional (either party may send). OSCP defines CP → FP (and FP → CO) with ack in the opposite direction.

One-to-one mapping of Group ID to Asset ID per site; both should reference the same site. Group IDs must be alphanumeric without spaces.
Instantaneous measurements: Vector supports kW/W only (A/WH/KWH are not accepted).
Aggregation required: all site charging data must be combined into a single asset payload before sending to Vector.

Forecast delivery: Vector sends updated group forecasts (DOE/charging profiles) every 15 minutes for a 24-hour horizon.
Application timing: Charge Operators should apply new limits as soon as possible and within 2 minutes of receipt.
Protective zero profiles: Vector may send all-zero capacity profiles during network issues; charging must stop until normal profiles resume.
Heartbeats: must be exchanged regularly; handshake required before other messages when offline.

Whether any OSCP optional fields (e.g., energy_type, initial_measure_time) are required/ignored by Vector.
Error handling expectations (custom headers or bodies) beyond HTTP 204/4xx/5xx.