1. Powsybl-Tsc
  2. Messages

IIDM Versionning - questions

VEDELAGO Miora
 

Hi all,


As you may know, we are currently working on the versionning of XIIDM.


In this context, the main question we have is: do we need to handle the serialization of different versions? At first, we wanted to be able to read/validate older versions but only write in the latest (i.e. current) version. However, this will bring a lot of restrictions in processing XIIDM files. Should we allow to serialize in older versions?


If the answer is yes, here are our proposition:

  • Handling of XIIDM breaking changes
During export, the responsability to check compatibility between the version the user wants to write in and the network itself (i.e. to check if every component of the network can be serialized in the given version) is on the serializers of the network components.
    • New equipments:
If a new equipment is added in version N, the user will only be able to serialize it in version N and newer (N+1, N+2...). If they try to serialize a network containing this equipment in older versions, an exception will be thrown by the equipment's serializer.
    • New attributes
      • optional:
If a new optional attribute is added to an equipment in version N, this equipment will be serializable in older versions (N-1, N-2...) if and only if this attribute has its default value. If its value is not the default value, an exception will be thrown by the equipment's serializer if serialization in older versions is attempted.
      • required:
If a new required attribute is added to an equipment in version N, an exception will be thrown by the equipment's serializer if serialization in older versions is attempted.

  • Handling of extensions versionning:
Some extensions are dependent on XIIDM (e.g. CurrentLimitsPerSeason depends on CurrentLimits modelisation in XIIDM). Hence, extensions should be versionned as well.

Some specific examples:
  • Changing of attributes name for steps: the attributes names will depend on the version the file is imported/exported
  • Addition of new attributes for shunt regulation
    • During import of 1.0 XIIDM files containing shunts, shunts will be considered as not regulating
    • During export as an 1.0 XIIDM file of a network, if the network only contains not-regulating shunts, it will be exported with the old modeling, else (if the network contains regulating shunts), it will throw an exception
  • New modeling to discriminate linear and non-linear shunts
    • During import of 1.0 XIIDM files containing shunts, shunts will be considered as linear
    • During export as an 1.0 XIIDM file of a network, if the network only contains linear shunts, it will be exported with the old modeling, else (if the network contains non linear shunts), it will throw an exception
  • Modeling changes for current limits: it will be considered as an extension
    • During import of 1.0 XIIDM file containing current limits, we will read them and import them as the new extension of the network
    • During export as an 1.0 XIIDM file, current limits will be serialized as they were in XIIDM 1.0 and/or (?) as an CurrentLimits extensions compatible with XIIDM 1.0 (todo)
  • Introduction of apparent power limits
    • If we model them as extensions, there will be no major compatibility issues
    • Else, it will mean creating a new field which cannot be serialized as XIIDM 1.0 and will throw an exception if it is attempted
Is it clear for you? Do you think writing in older versions should be an implemented feature? If you do, do you agree with our propositions? Have you something to add to them? If you don't, how should we handle old versions files in your opinion? Don't hesitate to describe specific use cases to press your point.


Miora RALAMBOTIANA
CHARGE DE PROJETS MAINTENANCE EXPLOITATION SI
PES - Direction Système d'information et Télécom - Département Développement Logiciel - Système électrique
miora.ralambotiana@...
rte-france.com 


"Ce message est destiné exclusivement aux personnes ou entités auxquelles il est adressé et peut contenir des informations privilégiées ou confidentielles. Si vous avez reçu ce document par erreur, merci de nous l'indiquer par retour, de ne pas le transmettre et de procéder à sa destruction.

This message is solely intended for the use of the individual or entity to which it is addressed and may contain information that is privileged or confidential. If you have received this communication by error, please notify us immediately by electronic mail, do not disclose it and delete the original message."

Join powsybl-tsc@lists.lfenergy.org to automatically receive all group messages.