Skip to content

The clean way of exporting time series #294

Description

@SanPen

Hi,

I'm implementing the export of time series data from VeraGrid to CGMES and I find the following predicament;

In VeraGrid a time series is simply an array of values that is associated with a property of an object. Time is a coordinated array that is the same for all profiles in the program. And many properties have a time series profile associated, like rates, active status, power injections, transformer set points etc. Watch this to understand more, but it is pretty straight forward.

My initial reaction is to simply generate a SSH file per time step.
However I see the chances of also generating NCP files.

The chat GPT take is:

 For VeraGrid profiles, I would not use “many SSH files” as the primary CGMES time-series
  encoding.

  Use this split instead:

  - SSH for one operating-state snapshot at one t_idx.
  - PS for time-varying active/reactive power setpoints.
  - SSI for baseline operational instructions that apply as the default state.
  - SIS for scheduled discrete changes over time: topology, taps, enable flags, control
    changes.
  - AVS for availability schedules.
  - SHS for time-varying steady-state hypothesis data such as in-service state, limits, tap
    schedules, regulator targets, storage state, and similar hypothesis/schedule data.

  So the rule is:

  - If you want interoperability with classic CGMES-only tools: export one full CGMES
    snapshot package per time step in a batch zip. That means repeated SSH-based snapshots,
    optionally with SV if you also want solved results.
  - If you want a native CGMES time-series representation: use the newer NCP profiles, not
    repeated SSH.

  For VeraGrid specifically, the clean recommendation is:

  - Power profiles of generators, loads, batteries, converters, external injections: PS
  - Binary/discrete profile changes: SIS
  - Constant instruction baseline before scheduled changes: SSI
  - Availability/on-off schedules: AVS
  - Limit/tap/target/in-service hypothesis trajectories: SHS

  So my recommendation is:

  - keep the current batch-of-snapshots export for compatibility
  - add a separate NCP export path for semantic time-series export
  - do not try to force all profiles into repeated SSH, because that loses the distinction
    between schedule, instruction, and hypothesis

  One more distinction matters:

  - SSH is a case state
  - PS/SIS/SSI/AVS/SHS are schedule or instruction semantics

  That distinction is worth preserving.

  If you want, I can turn this into a concrete VeraGrid export mapping table and then
  implement the first NCP export subset, with PS + SSI + SIS first.

From the design point of view, I'd say the profiles override an existing profile functionality (the SHH), since today for RCC 's communication, TSO's are forced to exchange several full CGMES files AKA many SHH, TP, etc, each with a date and time somehow. And as preposterous as this is, it is the norm.

I see a cleaner approach in having time series data into the profiles, so what is the recommendation here?

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions