MeterReadings and references

[narve]

The MeterReading schema and endpoint descriptions, as defined by the UMEI standard, is also used for direct communication between FSPs and DSOs. This integration revealed some missing information in our data model.

A MeterReading can be connected either to a portfolio (as defined in UMEI), or to "something else"; typically an asset (part of a portfolio), an asset grid assignment (the link between an asset and the physical grid), a MPID (metering point ID), a grid node id, etc.

The MeterReading model does not account for this. While direct FSP and DSO communication is not covered by the UMEI protocol, it would be good if the protocol can be used as widely as possible. In any case the integration of the market participants in the eUniversal projects are important for a successful completion of the project. Hence we should see if we find a way to solve this problem.

[narve]

I will propose a few solutions to get the discussion started:

• Allow "additional properties" on the MeterReading model and let DSOs/FSPs sort it out between themselves

• Add AssetId, AssetGridAssignmentId etc as needed, as nullable string references, to the MeterReading model

• Make references more generic, e.g. by splitting the current AssetPortfolioId into two fields, "SourceReference" (containing the ID) and "SourceReferenceType" (containing e.g. the string "Portfolio" to indicate that the ID refers to a portfolio)

• Allow a list of references, e.g. add field "SourceReferences" containing an array of [Reference, ReferenceType] pairs.

• Adopt a URI-like namespace scheme, e.g. portfolio:432432 or umei:portfolio:54435, and rename AssetPortfolioId to something more generic, e.g. SourceReference

[cdmNSIDE]

Out of curiosity, is it the same problem with the baselines ?

[cdmNSIDE]

What I would propose it to indeed remove the field "portfolioId" from the MeterReadings and have instead "sourceId" (or "SourceReference") and "sourceType" (or "SourceReferenceType").
We could use an enum to define the allowed valued for SourceReferenceType (Portfolio/asset/ ...)
But for the moment the assets are not indicated at all in the UMEI. For instance, the portfolios only refer to a gridNodeId, but not to a list of assets. I wonder if it will be sufficiant.

[cdmNSIDE]

@ArnaudDebray Any opinion on this ?

[narve]

Out of curiosity, is it the same problem with the baselines ?

Possibly, although not necessarily. Note that trading happens on portfolios, thus baselines are relevant for portfolios, not for individual assets.

One could argue that the same goes for meter readings: It is up to the meter reading providers to aggregate meter readings as necessary, so that the FMO always operate on portfolio level.

Of course, to make things easier for the participants the FMO could do the aggregation. This is the way NODES operate.

However, that does raise several issues, both technical (need to know which assets where part of the portfolio at the given time, etc) and non-technical (do the FMO have access to enough information? Are they allowed to store these values? Perhaps only for periods in which there have been trades for the relevant portfolio?)

[narve]

Regarding leaving the meter reading aggregation to the participants / meter reading providers: This is also not entirely obvious, since the FMO is the "source of truth" regarding which assets are part of which portfolios at any given time.

[narve]

I think this situation is complicated, and also that it will vary between differnt FMOs and between different markets/regions. It is certainly too large a topic to solve completely in the UMEI in the current scope.

Therefore I am in favour of making the API flexible enough to handle most cases and leave the details (including validation) to the FMOs. This will of course require proper validation and reasonable error message in case of invalid references.

Regarding how we technically store the reference, I think the most flexible solution is to adopt a URI-like scheme, and leave the details to the FMO. If we split it into source-reference and source-type we should define source-types, possible as an enum, but then we need to agree on the contents of the enum. In addition, this is less flexible for those cases where the meter reading is given more than one reference. E.g. in our cases we receive meter readings that are linked to both Metering Point Id (MPID) and to portfolio, in which case we validate that the MPID is correct for the portfolio at the time of the meter reading.

[ArnaudDebray]

hello,

On one side I don't see the point of having a FMO that would receive aggregated orders but non-aggregated baselines or meter readings. That looks very strange to me.

On the other side, I understand that leaving this aggregation to the FSP without validation/control possibility can lead to serious risks in the market.

For this issue we really need the inputs from Mahtab and Mitnetz to understand the validation process of meter readings (and baselines)