Consumption Data – AT

How to get access to Austrian Validated Historical Consumption Data and Master Data through EDA Customer Consent Management (CCM).

First of all, Austria features a highly standardised, distributed and de-centralised Energy Market Communication Infrastructure called “EDA – Energiewirtschaftlicher Datenaustausch”, run by the EDA GmbH ( https://www.eda.at ). EDA is owned by the Austrian grid operators and drives smart grids communication nationally. The specificity here is, that developments are not particularly driven by a single player, but by working groups organised by Austrian Energy Association (Oesterreichs Energie (OE) – https://www.oesterreichsenergie.at ). All new process families are standardised through public consultations on the website http://www.ebutilities.at. Processes and data exchange requirements are published on the website and available to all. Basis for the communication / exchange of XML – based messages that drive these procedures, is the OASIS AS/4 Standard ( http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/profiles/AS4-profile/v1.0/os/AS4-profile-v1.0-os.html ) realised in Austria by Ponton X/P Messenger ( https://www.ponton.de/products/xpmessenger/ ). As the topic is driven by the regulated domain, it is always ensured that there are low entry barriers for market communication. Therefore, EDA features 3 ways of participating in market communication/ data access:

  • A – Download of data through a web portal (very low barrier, free)
  • B – Exchange of messages through an sMIME/Secure Email Gateway, that communicates with the EDA infrastructure (low barrier, free below a usage threshold)
  • C – Full stack using an instance of Ponton X/P Messenger (reasonable license fee to pay to contribute to maintenance and market communication development)

General information

If you simply want to download your meter data, you can do this via loggin in with your customer account at your DSO’s portal. Metering markets are bound to the geographical area you live in Austria. DSOs have the following characteristics and Market Communication identifiers:

Lage von Wien in Österreich
image from Wien – Wikipedia
Name: Wiener Netze GmbH
AT-Code: AT001000
Website: https://wienernetze.at
Metering grid area: Vienna Region
Niederösterreich in Austria.svg
image from Niederösterreich – Wikipedia
Name: Netz Niederösterreich GmbH
AT-Code AT002000
Website: http://www.netz-noe.at
Metering grid area: Lower Austria
Oberösterreich in Austria.svg
image from Oberösterreich – Wikipedia
Name: Netz Oberösterreich GmbH
AT-Code: AT003000
Website: http://www.netzooe.at
Metering grid area: Upper Austria
Salzburg in Austria.svg
image from Land Salzburg – Wikipedia
Name: Salzburg Netz GmbH
AT-Code: AT004000
Website: https://www.salzburgnetz.at/
Metering grid area: Salzburg
Tirol in Austria.svg
image from Tirol (Bundesland) – Wikipedia
Name: TINETZ-Tiroler Netze GmbH
AT-Code: AT004000
Website: https://www.tinetz.at/
Metering grid area: Tirol
Vorarlberg in Austria.svg
image from Vorarlberg – Wikipedia
Name: Vorarlberger Energienetze GmbH
AT-Code: AT006000
Website: https://www.illwerkevkw.at/vorarlberger-energienetze-gmbh.htm
Metering grid area: Vorarlberg
Kärnten in Austria.svg
image from Kärnten – Wikipedia
AT-Code: AT007000
Website: https://kaerntennetz.at/
Metering grid area: Kärnten
Steiermark in Austria.svg
image from Steiermark – Wikipedia
Name: Energienetze Steiermark GmbH
AT-Code: AT008000
Website: https://www.e-netze.at/
Metering grid area: Steiermark
Burgenland in Austria.svg
image from Burgenland – Wikipedia
Name: Netz Burgenland GmbH
AT-Code: AT009000
Website: https://www.netzburgenland.at/
Metering grid area: Burgenland
Austrian DSOs and their (rough) regional responsibility ( see https://ebutilities.at/utilities/marktpartner/?Filtered=1&FilterBranche=1&FilterRole=1&FilterStatus=1&submit2=Filter+anwenden )

Onboarding as an Eligible Party

Option A

If you simply want to take part using Option A without the need for automation, you have the option to become set up as a portal user on ( https://www.eda-portal.at/de ), whereas currently this option is mainly reserved for operators of common generation facilities and energy communities. Information on Registration can be found here on https://www.eda-portal.at/de/Registrierung . As this is – due to the lack of automation capability – not too interesting for data-based services, I will not explain that option in detail here (maybe later).

Option B

Option B – onboarding as an email user

The steps that a data-driven service/ eligble party needs to do, are:

Keep in mind that the email way is a free usage tier until you reach a certain threshold of monthly messages.

Option C

Option C – onboarding as a full stack user

The steps that a data-driven service/ eligble party needs to do, are:

  • Register Name, Email etc. on ebUtilities.at: go to https://ebutilities.at/utilities/marktpartner/registration/index.php and register as “Energiedienstleister”. Then wait for your account to be confirmed. You will get an AT-Code (market partner identification of the form EP100023).
  • Download and sign the EDA Contract as a full-stack user and send it back.
  • Register as a full-stack EDA user on https://jira.ponton.de/servicedesk/customer/portals .
  • Open a ticket there and request to be set up as a full-stack partner. Then follow the advice of Ponton support.
  • Setup Ponton X/P Messenger and Listener following the integration guide you will get in the process.
  • Request SSL certificate from Ponton.
  • Request partner certificate, report communication information (IP address or DNS name, port)
  • Request and install credentials for EDA partner registry.

Keep in mind that the full-stack option will include some cost sharing, fees will be stated in the contract with EDA GmbH.

Requesting data as an Eligible Party

Now, as we are onboarded, we can request data from a customer. To do this, we should check EDA process family Customer Consent Management. Process and schema documentation can be found here: https://www.ebutilities.at/utilities/prozesse/kategorien/detail.php?ProcessCategoryID=14&ReturnTo=%2Futilities%2Fprozesse%2Fkategorien%2F

In a step-by-step way, please see the following example:

  • I – as Energiedienstleister ‘Hartner Email Tests’ (AT-Code EP100023) – need consumption data from a customer with metering point id AT0090000000000000000000000097711 (Mr. Max Mustermann from Energie Burgenland. For my service, I need data from the past (Jan 1st 2021 to Dec 31st 2021) and future data (Mai 1st to Nov 30th 2022).
  • To achieve this, I have to generate a “ConsentRequestId” and fill the fields of a CMRequest message properly (for the full-blown schema documentation, please refer to https://www.ebutilities.at/documents/20211227111142_CMRequest_01p10_Schemadoku.pdf ):
<cp:CMRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:cp="http://www.ebutilities.at/schemata/customerconsent/cmrequest/01p00"
xmlns:ct="http://www.ebutilities.at/schemata/customerprocesses/common/types/01p20"
xsi:schemaLocation="http://www.ebutilities.at/schemata/customerconsent/cmrequest/01p00 CMRequest_01p00.xsd">
  <cp:MarketParticipantDirectory DocumentMode="PROD" Duplicate="true" SchemaVersion="01.10">
    <ct:RoutingHeader>
      <ct:Sender AddressType="ECNumber">
        <ct:MessageAddress>EP1000023</ct:MessageAddress> <!-- my eligible party AT-code -->
      </ct:Sender>
      <ct:Receiver AddressType="ECNumber">
        <ct:MessageAddress>AT009000</ct:MessageAddress> <!-- AT-Code of Netze Burgenland -->
      </ct:Receiver>
      <ct:DocumentCreationDateTime>2022-01-17T09:30:47Z</ct:DocumentCreationDateTime>
    </ct:RoutingHeader>
    <ct:Sector>01</ct:Sector>
    <cp:MessageCode>ANFORDERUNG_CMQF</cp:MessageCode>
  </cp:MarketParticipantDirectory>
  <cp:ProcessDirectory>
    <ct:MessageId>GC100007201912170930001230001234567</ct:MessageId> <!-- see schema docs above for an algorithm -->
    <ct:ConversationId>GC100007201912170930001230012345678</ct:ConversationId> <!-- see schema docs above for an algorithm -->
    <cp:ProcessDate>2022-01-17</cp:ProcessDate> <!-- today's date -->
    <cp:MeteringPoint>AT0090000000000000000000000097711</cp:MeteringPoint> <!-- metering point id of customer (if not known, leave out) -->
    <cp:CMRequestId>IWRN74PW</cp:CMRequestId> <!-- see schema docs above for an algorithm, will be used by customer to find req -->
    <cp:CMRequest>
      <cp:ReqDatType>GCLoadProfiles</cp:ReqDatType>
      <cp:DateFrom>2022-05-01</cp:DateFrom>
      <cp:MeteringIntervall>QH</cp:MeteringIntervall>
      <cp:TransmissionCycle>M</cp:TransmissionCycle>
    </cp:CMRequest>
  </cp:ProcessDirectory>
</cp:CMRequest>

Now, the customer has to log in to Netze Burgenland portal and provide his credentials to log in. Then, he would hit “Request ID bearbeiten”

and enter the string that we have sent as CMRequestId in the message above.

If he now accepts the CMRequest, we would receive back a message (CMNotification) just like the one below.

<cp:CMRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:cp="http://www.ebutilities.at/schemata/customerconsent/cmrequest/01p00"
xmlns:ct="http://www.ebutilities.at/schemata/customerprocesses/common/types/01p20"
xsi:schemaLocation="http://www.ebutilities.at/schemata/customerconsent/cmrequest/01p00 CMRequest_01p00.xsd">
  <cp:MarketParticipantDirectory DocumentMode="PROD" Duplicate="true" SchemaVersion="01.10">
    <ct:RoutingHeader>
      <ct:Sender AddressType="ECNumber">
        <ct:MessageAddress>EP1000023</ct:MessageAddress> <!-- my eligible party AT-code -->
      </ct:Sender>
      <ct:Receiver AddressType="ECNumber">
        <ct:MessageAddress>AT009000</ct:MessageAddress> <!-- AT-Code of Netze Burgenland -->
      </ct:Receiver>
      <ct:DocumentCreationDateTime>2022-01-17T09:30:47Z</ct:DocumentCreationDateTime>
    </ct:RoutingHeader>
    <ct:Sector>01</ct:Sector>
    <cp:MessageCode>ANFORDERUNG_CMQF</cp:MessageCode>
  </cp:MarketParticipantDirectory>
  <cp:ProcessDirectory>
    <ct:MessageId>GC100007201912170930001230001234567</ct:MessageId> <!-- see schema docs above for an algorithm -->
    <ct:ConversationId>GC100007201912170930001230012345678</ct:ConversationId> <!-- see schema docs above for an algorithm -->
    <cp:ProcessDate>2022-01-17</cp:ProcessDate> <!-- today's date -->
    <cp:MeteringPoint>AT0090000000000000000000000097711</cp:MeteringPoint> <!-- metering point id of customer (if not known, leave out) -->
    <cp:CMRequestId>IWRN74PW</cp:CMRequestId> <!-- see schema docs above for an algorithm, will be used by customer to find req -->
    <cp:CMRequest>
      <cp:ReqDatType>GCLoadProfiles</cp:ReqDatType>
      <cp:DateFrom>2022-05-01</cp:DateFrom>
      <cp:MeteringIntervall>QH</cp:MeteringIntervall>
      <cp:TransmissionCycle>M</cp:TransmissionCycle>
    </cp:CMRequest>
  </cp:ProcessDirectory>
</cp:CMRequest>

CMRequest – Message to send to Netze Burgenland to initiate data access. After this, when data is ready, you will receive messages with ConsumptionRecord messages. They will look like:

<?xml version='1.0'?>
<ns0:ConsumptionRecord xmlns:ns0="http://www.ebutilities.at/schemata/customerprocesses/consumptionrecord/01p21">
    <ns0:MarketParticipantDirectory DocumentMode="SIMU" Duplicate="false" SchemaVersion="01.21">
        <ns0:RoutingHeader>
            <ns0:Sender AddressType="ECNumber">
                <ns0:MessageAddress>AT009000</ns0:MessageAddress>
            </ns0:Sender>
            <ns0:Receiver AddressType="ECNumber">
                <ns0:MessageAddress>EP1000023</ns0:MessageAddress>
            </ns0:Receiver>
            <ns0:DocumentCreationDateTime>2021-03-25T09:44:59.6382460Z</ns0:DocumentCreationDateTime>
        </ns0:RoutingHeader>
        <ns0:Sector>01</ns0:Sector>
        <ns0:MessageCode>DATEN_CRMSG</ns0:MessageCode>
    </ns0:MarketParticipantDirectory>
    <ns0:ProcessDirectory>
        <ns0:MessageId>AT009000202103251043556270002049802</ns0:MessageId> <!-- see schema docs above for an algorithm -->
        <ns0:ConversationId>AT009000202103240714429251000702517</ns0:ConversationId> <!-- see schema docs above for an algorithm -->
        <ns0:ProcessDate>2022-03-25</ns0:ProcessDate>
        <ns0:MeteringPoint>AT0090000000000000000000000097711</ns0:MeteringPoint>
        <ns0:Consumption>
            <ns0:MeteringReason>00</ns0:MeteringReason>
            <ns0:MeteringPeriodStart>2022-03-24T00:00:00+01:00</ns0:MeteringPeriodStart>
            <ns0:MeteringPeriodEnd>2022-03-24T23:59:00+01:00</ns0:MeteringPeriodEnd>
            <ns0:MeteringIntervall>QH</ns0:MeteringIntervall>
            <ns0:NumberOfMeteringIntervall>96</ns0:NumberOfMeteringIntervall>
            <ns0:ConsumptionData MeterCode="1-1:1.9.0 P.01">
                <ns0:ConsumptionPosition>
                    <ns0:DateTimeFrom>2022-03-24T00:00:00+01:00</ns0:DateTimeFrom>
                    <ns0:DateTimeTo>2022-03-24T00:15:00+01:00</ns0:DateTimeTo>
                    <ns0:MeteringMethod>L2</ns0:MeteringMethod>
                    <ns0:BillingUOM>KWH</ns0:BillingUOM>
                    <ns0:BillingQuantity>0.500000</ns0:BillingQuantity>
                </ns0:ConsumptionPosition>
                <ns0:ConsumptionPosition>
                    <ns0:DateTimeFrom>2022-03-24T00:15:00+01:00</ns0:DateTimeFrom>
                    <ns0:DateTimeTo>2022-03-24T00:30:00+01:00</ns0:DateTimeTo>
                    <ns0:MeteringMethod>L2</ns0:MeteringMethod>
                    <ns0:BillingUOM>KWH</ns0:BillingUOM>
                    <ns0:BillingQuantity>0.500000</ns0:BillingQuantity>
                </ns0:ConsumptionPosition>
                ...                
        </ns0:Consumption>
    </ns0:ProcessDirectory>
</ns0:ConsumptionRecord>

Leave a comment