Error Taxonomy as Shared Infrastructure: Cross-OEM Fault Intelligence

Consider a portfolio running Huawei string inverters at three sites, Enphase microinverters at two, and Solarman-connected loggers at another. Each OEM describes faults in its own vocabulary. One encodes communication loss as a numeric state, another as a text alarm, and another as a missing data interval. Without normalization, your alerting and triage logic is comparing unlike events — and every cross-site fault analysis requires vendor-specific branching.

ODSE addresses this by requiring a shared error_type contract while preserving source diagnostics in error_code_original. This gives you a common language for decision-making without losing root-cause traceability.

Why a Shared Taxonomy Changes Outcomes

• You can reuse alert thresholds across OEM cohorts.
• Your incident rollups become comparable across sites and vendors.
• False dispatch analysis becomes measurable fleet-wide.
• Triage ownership can be based on severity classes, not vendor expertise alone.

Contract Mechanics in ODSE

ODSE defines supported error_type values and expects your transform logic to map OEM-native signals into that shared enum set. At the same time, the raw source code remains available for diagnostic drill-down.

OEM state/code -> transform mapping -> error_type + error_code_original -> validate() -> downstream fault analytics

Implementation Pattern

Step 1: Build Source Mapping Tables

For each OEM connector, define explicit mappings from vendor status/error payloads into ODSE error_type. Keep this mapping versioned and review it whenever OEM payloads change.

Step 2: Preserve Diagnostic Evidence

Never discard source-level signals. Store the original code or state string in error_code_original so your field teams can still investigate vendor-specific root causes.

Step 3: Validate for Contract Integrity

Run schema validation to enforce enum correctness, then semantic validation to catch suspicious state/value combinations. This prevents contract drift and bad cross-site comparisons.

Reference Example

from odse import transform, validate

rows = transform("fleet_dump.csv", source="huawei")
result = validate(rows)

if not result.is_valid:
    raise ValueError(result.errors)

# downstream analytics now consume normalized error_type values

Operational Dashboard Design

Once fault events are normalized, your first dashboard should answer three questions:

• Which error_type classes drive the most downtime by site cohort?
• Which fault classes create the most false dispatch events?
• Where do fault frequencies shift after firmware or maintenance changes?

These questions are impossible to answer reliably when each OEM remains in its own taxonomy island.

Common Failure Modes

• Directly passing OEM codes to analytics without mapping them through ODSE.
• Allowing unsupported enum values to enter storage.
• Dropping original source codes and losing diagnostic context.
• Treating missing telemetry as equivalent to explicit fault states.

Acceptance Criteria for "Taxonomy Done"

• All active OEM feeds emit only valid ODSE error_type enums.
• Every mapped fault keeps source traceability via error_code_original.
• Cross-OEM incident rollups run without vendor-specific exceptions.
• Validation errors and warning trends are visible in your operations reporting.

Shared error semantics are not optional polish. They are the minimum infrastructure required for trustworthy, portfolio-scale reliability intelligence.

Energy Timeseries Schema | Transforms | Semantic Validation