FAQ

General

  • Is it possible to use one EAN-code for different roles (e.g. shipper and supplier)?

    Yes, this is possible. If the shipper and supplier role are combined, and only one EAN-code is used, this party will receive (from GtS) all messages for the supplier and all messages for the shipper. The information in those messages can be different. E.g.: the TINFO will be the same but the LALL will be different. Please be aware that the backoffice systems must be capable of handling these messages. Sending messages to other parties will be encrypted and signed with one security key for all messages. Communication takes places through one AS2 connector and IP-address. Per EAN-code one Private Key Certificate will be issued. If the shipper role and the supplier role have their own EAN-code the messages will be sent per role and encrypted with the certificate which belongs to that role. The AS2 application must be capable of handling this difference, e.g. must use seperate IP-addresses or different url´s (webpages) to receive messages. It is preffered to use a seperate EAN-code for each role.

  • Can I use old email messages after 1-1-2004?

    No, new messages (as defined in the MIG) are the only ones other parties can use. The old email messages do not contain all necessary information and the other parties have only implemented the new MIG-messages.

  • What is a working day?

    The following days are not working days in the framework of the PVE message traffic:

    Weekend:

    • Saturday
    • Sunday

    National holidays:

    • Koninginnedag (Queen´s Day) 30 April)
    • Liberation Day (5 May)

    Generally recognised and Christian holidays:

    • New Year´s Day (1 January)
    • Good Friday
    • Easter Day
    • Ascension Day
    • Whitsun
    • Christmas (25, 26 December)

     

VPN AS2

  • We, as a party, have multiple roles. However, my AS2 software is not able to send messages depending on the role (and therefore EAN-code) which defines the addressee, using the associated digital certificate. Furthermore, it is only possible to configure

    Doel
    Dit document is bedoeld om alle betrokken partijen te informeren omtrent een zaak die speelt rond AS2 communicatie. Dit document beschrijft geen directe oplossing voor een probleem, wel een workaround, dat wordt beschreven, maar is bedoeld om onduidelijkheid weg te nemen.

    Berichtenuitwisseling
    Iedere partij die berichten uitwisselt op het VPN heeft een eigen unieke EAN-code. Als een partij meerdere rollen vervult, is het aanbevolen (maar niet afgedwongen) dat ook voor iedere rol een eigen EAN-code beschikbaar is. Hiermee is iedere zender en ontvanger van berichten op het VPN uniek. Op basis van de EAN-codes worden vervolgens de certificaten uitgegeven, waardoor een koppeling ontstaat tussen EAN-code en digitaal certificaat. Door deze ‘koppeling’ is het dus mogelijk om de identiteit van een zender niet alleen vast te stellen op basis van de EAN-code, maar ook te verifiëren op basis van het gebruikte certificaat. Door deze ‘koppeling’ is het mogelijk om
    “EAN-code <=> certificaat” combinaties te detecteren en (afhankelijk van de gebruikte AS2 software) de berichten te weigeren of te accepteren.

    Situatie
    Op dit moment doet zich de situatie voor dat er AS2 software wordt gebruikt door partijen die het berichtenverkeer voor meerdere rollen afhandelen (Shipper, RNB, Leverancier rol of meerdere rollen van een soort) op één IP adres (een server). Sommige AS2 software is echter (nog) niet in staat om afhankelijk van de rol (en dus EAN-code), waarvoor een bericht wordt verstuurd, het bijbehorende digitale certificaat te gebruiken. Daarnaast doet zich het probleem voor dat het alleen mogelijk is om 1 URL te configureren waar de berichten naar toe gestuurd worden.

    In de praktijk komt het er op neer dat deze AS2 software alle berichten voor alle rollen verstuurt onder de identiteit (dus het certificaat) van een van de rollen en dat alle berichten naar één mogelijke URL van de ontvangende partij worden gestuurd.

    Afhankelijk van de AS2 software die aan de ontvangende zijde wordt gebruikt, levert bovenstaande een probleem op als een aparte URL per rol (bijv. het gebruik van een EAN code in de URL) is gespecificeerd voor het ontvangen van de berichten.
    Per URL is dan ook alleen het bijbehorende certificaat beschikbaar voor het controleren van de identiteit van de verzender.

    Gevolgen
    Voor zover nu bekend is doet het bovenstaande probleem zich voor bij partijen die XIB/Cyclone commerce AS2 software gebruiken. Naar nu bekend treden er in de communicatie met partijen die HP CATS gebruiken problemen op.

    Workaround
    De mogelijke work around is dat de betrokken partijen onderling afspreken dat de communicatie richting HP CATS via 1 URL en digitaal certificaat wordt afgewikkeld (één van de rollen). Dit betekent dus ook dat de berichten komend van een XIB/Cyclone commerce systeem onder 1 identiteit worden verstuurd en dus, voor alle berichten naar een (HP CATS) partij, het certificaat zal gebruiken dat bij die ene, afgesproken, EAN-code hoort.

    Partijen waarbij dit speelt zullen dit dus onderling moeten afstemmen. Houd dit in het achterhoofd: De oplossing van dit probleem wordt dus gelegd bij de partij die zelf geen probleem heeft.

    Dit is een tijdelijke work around, partijen die gebruik maken van software die problemen geeft (XIB/Cyclone commerce) zullen met hun softwareleverancier in contact moeten treden en erop moeten aandringen om de software aan te passen.

  • Are there specifications for the setup of AS2?

    Yes.
    Encryption: 3DES
    Signing: SHA1
    Compression: on
    MDN: Synchronous signed
    AS2 to/from: EAN code as identifier
    No server certificate (thus no HTTPs)

  • What bandwidth does Gas Transport Services have, for example with the BT network?

    A 2Mb connection.

  • According to your estimates, how much data do we need to take into account?

    This is an estimate that one must make oneself. The following is a sample calculation:
    Estimation of VPN connection bandwidth

    To estimate the time required to transfer allocations in a ´worst-case´ scenario, the following formula can be used:
    Transfer Time = Max #messages * Max message size (in bytes) * 8
    0.9 * Bandwidth (bits/sec) * Feff * Fcomp

    Variables:
    Max #messages
    Max. number of messages = Maximum number of allocation points = 400 (for GtS)

    Max message size
    The size of the message is determined by the average number of suppliers and the average number of suppliers per category. The messages that are defined in the MIG (Message Implementation Guidelines for PVE messages (draft- v.4), prescribe that one message holds all allocations for every supplier/category combination for a single allocation point. For the ´worst-case´ scenario, we will use the largest message which is the LALL-message.
    Based on previous assumptions, the size of the message is approximately 1500K.

    Other variables
    For the transmission of the messages, AS2 is used which uses compression. The compression factor (as measured during tests) is 25 and denoted as Fcomp.
    Using a messaging protocol also generates some overhead. The efficiency-factor, Feff, is estimated at 0.7.
    Furthermore, we estimate that 90% of the bandwidth is used by message-transfers. This is because it is also possible that return messages are sent simultaneously. This factor we estimate at 0.9.
    Last but not least is the number of bits in a byte, 8.

    An example for GtS:

    Transfer Time = 400 * 1500000 * 8 = 171 sec.
    0.9 * 2000000 * 0.7 * 25

    This calculation is based on a 2Mbit/sec connection for GtS.
     

  • What does the rest of the infrastructure of Gastransport Services consist of?

    The infrastructure consists of Biztalk with Covast EDI accelerator and AS2 adaptor: behind this there is a message handler that sends back the confirmation messages. Behind the message handler there is a sort of business warehouse in which all the relationships between allocations, market parties, and so forth are stored.

  • What specifications do the different server components have for the AS2 EDI message traffic?

    This depends completely on the solution chosen: so sizing must be done based on our current knowledge. During the trial run it must be possible to tune the system, and make it smaller (not usually the case) or larger. The system must be easy to resize. There are solutions based on one server, but one can also consider load-balancing scenarios. In addition the question as to in which systems particular processes take place must be answered. Gastransport Services has split the functionality into messaging (translation and communication), checking (checking the message contents and confirming), and processing/generating (making all the calculations and generating the correct message content).

  • How do I set up the network infrastructure as regards NAT, IP addresses, firewall, etc?

  • If I do not yet have a VPN connection, can I still start with KEMA testing?

    The procedure is such that first a VPN connection must be requested and installed. After the signing of the contract with BT Nederland (watch out for the throughput time) and the placing of the order, within 40 working days a VPN connection is delivered. There are some parties where the requesting of this connection resulted in a delay (not the fault of BT Nederland), but who still have the system ready. In order to meet these parties´ wishes, investigations have been made into whether it is possible to obtain access to the KEMA test facility in another way. After weighing up various possibilities*, it seems that a direct ISDN connection to KEMA is the fastest solution that does not affect the integrity of VPN. The expectation is that from 1 November a connection with KEMA can be made. The availability of a Cisco ISDN router is still a doubtful factor: an ISDN line must also be installed. If a party wants to be considered for this solution, they must announce this via the NOVA-postbus, after which the party will be planned in. The assumption is that the internal testing has been gone through (with good results): for this the spreadsheet can also be used (can be requested via nova@gasunie.nl). The precise filling out and the procedures must still be laid down. The party that wants to test must have a Cisco router available to avoid incompatibility at the hardware level.*) The following possibilities were considered:

    Via internet
    KEMA has a route from the internet to the test facility
    IP numbering problem.
    A lot of effort needed to guarantee security: KEMA is not yet connected to the internet
    No use being made of SSL
    - Via ISDN to GtS and then to VPN
    Throughput time approximately 7 weeks in connection with ordering the router
    NAT configuration is such that GtS is not reachable during testing by third parties. Also schaduwdraaien met GtS is thereby not possible simultaneously with KEMA testing
    - Sending test files via e-mail
    No realistic situation/test
    Testing takes place by means of message exchange and not with files. (People can carry out part of the testing themselves by means of the spreadsheet)
    - Physical access to KEMA
    This is only possible if it concerns a small system (PC solution)
     

LET/CET

  • What are the consequences for the date definition of EDIG@S (= UTC 0) in connection with the fact that GTS has decided to use LET (Local European Time) as from 1 January 2004?

    Functional
    Functionally (see the final report from PVE working group 12) the MINFO, LALL, BALL, CINFO messages apply to a gas month in LET and the TINFO message to a gas day in LET. This means that the first hour of such a message runs from 06:00 to 07:00 LET and the last hour from 05:00 to 06:00 LET.

     
    Technical
    As given in the Edigas MIG introduction, section 4.2.1, Time identification, it is extremely recommended to use UTC as the time basis in the messages. We are following this recommendation and thus we do not use LET in the Edigas messages. The consequence, among others, is that we are nor confronted with double messages with the switch from summertime to wintertime or wintertime to summertime (as described in section 4.2.2).


    Example
    A LALL message is sent for the month of March 2004. At the end of March the switch from wintertime to summertime will take place.

      1st hour of the message last hour of the message
    Functionally 06:00 - 07:00 LET 05:00 - 06:00 LET
    Technically 05:00 - 06:00 UTC 03:00 - 04:00 UTC

     

  • What is the reason for GTS using LET??

    This conforms to agreements between gas companies in a European connection.

  • We have noticed that with the change from wintertime to summertime (and vice versa) there is a chance that several messages are received with the same date.

    This is not the case: see above.

Edigas allocation-spreadsheet

  • Where can we find the spreadsheet?

    On the website accessible via the VPN. If you like to receive the spreadsheet earlier, you can ask for it via nova@gasunie.nl after 1 July 2003.

  • Is it necessary to test the spreadsheet at the KEMA?

    Yes, only for the spreadsheet in combination with a HP Cats solution an abbreviated testset is applicable.

  • The spreadsheet gives some problems running on Windows 98. Can this be a problem in Windows?

    The spreadsheet has been tested by Gas Transport Services under Windows 2000 and Microsoft Office 2000. Of course you are free to use the spreadsheet under a different configuration, but this is at your own risk.

KEMA-testing

  • What steps must I take in order to be able to start testing?

    To be able to start testing you must make contact with KEMA. KEMA will provide you with a digital test certificate whereby you can run the tests that are necessary for receiving the Attestation of Conformity.

  • If I do not yet have a VPN connection, can I still start with KEMA testing?

    The procedure is such that first a VPN connection must be requested and installed. After the signing of the contract with BT Nederland (watch out for the throughput time) and the placing of the order, within 30 working days a VPN connection is delivered.

  • We receive messages that we do nothing with at the moment (for example TINFO messages for the shipper). Must we still include these messages in the KEMA test?

    Per role it is determined which messages are sent and which are therefore also tested. If a party chooses not to use a particular message, this message must still be tested if it belongs to the party´s role.

MINFO-message

  • In the MINFO message does Gas Transport Services supply the measurement data at GOS or at PseudoGOS level?

    The MINFO message will, in contrast to the current situation, contain the measurement data per PseudoGos. This has been chosen in the PVE because the regional allocation takes place per Pseudo-Gos and the results thereof (the LALL message) is therefore also sent per Pseudo-Gos.

  • Is GTS at all familiar with the PseudoGos arrangement?

    Yes, namely GtS enters into transport contracts with shippers per Pseudo-Gos. The list of contractual measuring points (the Pseudo-Gosses among others) is on the GTS website.

TINFO-mesage

  • What is the number of temperature regions to be used in 2004 and what are their names and EAN-codes?

    PVE has decided to use one temperature region in 2004. The name is: De Bilt and the EAN-code is 871718518990000019.

  • In the TINFO messages, the words ´temperature zone´ are used in the definition of the LOC segment. Can I conclude from this that a temperature zone is the same as a region?

    The definition of temperature zone is not yet definitively determined. A study is still being conducted by Ecofys: in this it will be determined how many temperature zones are needed. This may possibly vary from one to four temperature zones for the whole country.

  • Can I conclude from this that GtS sends the temperature values per region (via a TINFO message) to the regional grid operators (RNBs)?

    If a choice is made for one temperature zone, all RNBs will receive the same TINFO message daily. If several temperature zones are defined, it must be determined for each measurement point (pseudo-Gos) in which temperature zone it is located. GtS will then distribute the TINFO messages per temperature zone to the regional grid operators.

  • Is a region identified by an EAN-18 code?

    A temperature zone is identified by an EAN-code.

  • If the answer to the previous question is in the affirmative, is there then a list of EAN-18 codes linked to regions?

    A maximum of four EAN codes will be made available in due course for identifying the temperature zone(s).

  • On page 11 (version 0.5, 2003.05.02) in the DATA CONTENT after 05, the ´temperature zone´ is given with a code. Is this the EAN code of the weather station?

    By ´temperature zone´ is meant that which is given in the PVE workgroup 12 final report as a temperature zone. Such a temperature zone is identified by an EAN code. For the profile calculations Holland will be divided into one or more temperature zones. The number of zones will be determined in PVE working group 3 (when is not clear).

  • In the final report of the PVE working group ´Elaboration on the allocation and nomination rules for gas´, version 1.0 dated 12 February 2003, it is stated that the TINFO message is a message that is sent monthly by GtS to the RNBs among others. In the pr

    Daily. The reason for this is that a network company in the case of a switch or the reconciliation process must have available the temperatures for the current month each day of the month. In this respect, a correction is made in version 1.10 (dated September 26, 2003).

  • Have you also got particular times when (at the latest) you send your messages (MINFO en TINFO)?

    From the PVE working group 12 final report: MINFO: For each (pseudo-) Gas Receiving Station GTS supplies, at the latest on the 4th working day after the end of the month at 07:00 LET the following data to the RNBs....
    The TINFO message will be sent out daily by GTS. Because of the uncertainty as regards the definition of the temperature zones, there is still no certainty about the timing of the daily sending of the messages.

Lall-messages

  • The various MIG´s go extensively into the content of the messages. How should a message be made?

    This information is in the PVE workgroup 12 final report. For the LALL message, for example, this is given in Appendix 2, Paragraph 5.1: The network company must cluster the data as follows:

     

    • the message for the supplier contains the allocations of the supplier concerned for all categories and for all shippers for a metering point
    • the message for the shipper contains the allocations of the shipper concerned for all categories and all suppliers for a metering point
    • the message for LNB contains the allocations of all shippers/suppliers/category combinations for a metering point, in other words all allocations for the metering point concerned.

    Thus the recipient of a LALL message only receives 1 message per metering point (pseudo-Gos), which includes all combinations of shippers/supplier/category.

  • In the examples in paragraphs 4.2.2 and 4.2.5 it is suggested that in one message per Gos (ed.)/metering point/pseudo-Gos the hourly values of a shipper/supplier/profile category are supplied. However, in the MIG template (paragraph 4.2.3) per shipper the

    Logically seen, in 1 message one or more combinations of shipper/supplier/profile category are given. Because we are dealing with the limitations of the EDIgas message MSCONS, these combinations are presented in slightly different ways in the message. However, they are present.

  • According to the remarks in the MIG of the LALL version 2.2 (and earlier) each LIN series contains the hourly labels of one gas day. According to the template structure in paragraph 4.2.3 and the template description in paragraph 4.2.4, the supplier ident

    Correct.

  • What is the reason to include the supplier for each gas day?

    This has to do with the structure that is possible in a MSCONS message. It is indeed not ideal: stating the supplier once per shipper/supplier/purchaser category combination would be enough. However, because the second NAD (0170.NAD) occurs within the LIN series of the gas day, this has to be stated anew for each gas day.

  • Can I include more suppliers per GOS/profile category in the message?

    Yes, for example:


    0100.NAD.1 Shipper: 1
    0110.LOC Metering point: PG Utrecht
    0130.RFF1 Category: GGV
    0170.NAD Supplier: A
    ..............................
    0130.RFF1 Category: GGV
    0170.NAD Supplier: B
    .................................
    0130.RFF1 Category: GGV
    0170.NAD Supplier: C
    .............................
    0130.RFF1 Category: GGV
    0170.NAD Supplier: D
    .........................

  • Are there any requirements for the message ID that is created?

    According to the LALL-EDIgas specification the syntax is as follows: DAYREPnnnnn, where nnnnn is a sequence number. This sequence number must be unique for the party concerned. Thus this number in combination with the EAN code is a unique identification.

Ball-messages

  • Is a separate BALL message per GOS sent to the supplier? Or are all connections for a supplier sent in one message and is GOS only an identification of the connection?

    The GOS does not appear (any more) in the BALL message, only the identification of the connection. The supplier is expected to know the connection register and thus to know behind which (pseudo-)Gos a connection exists. There may be several connections combined in one BALL message. It is not necessary to send all connections behind a (pseudo-)Gos in one BALL message. It is allowed, of course. From the direct (industrial) connections to the GtS-grid, BALL messages will be sent per connection.

  • At this moment we receive ´message 6´ as a forerunner of the data that as from 2004 will be sent in a BALL message. Can we assume that all measurement messages that are related to 2003 consumption will be sent by means of a ´message 6´, also if these are

    The exchange of information that is related to 2003 will continue to take place as it currently does, also if these messages are not sent until 2004. The new message traffic for the data will start as from 1 January 2004 (6:00 AM).

CINFO-messages

  • When must you have received the PALL and CINFO messages at the latest? It is not explicitly stated in the measurement regulations?

    GTS does not receive the PALL message (it is only sent to the supplier). For the CINFO message the same times apply as for the allocation BALL and LALL messages, namely: on the seventh working day, 00:00 hours LET (version 1) and the seventeenth working day, 00:00 hours LET (version 2). For more information see the final report of the PVE working group 12.

Pall-messages

  • If the PALL messages are of no interest to us, must we then install/test Endine applications?

    The PALL messages are sent to suppliers of profile purchasers. If you do not fulfil this role, the RNBs (regional grid operators) will therefore not send you the PALL message. Then there is also no need for you to implement this message.

Daily allocation

Dagallocaties.pdf pdf (57kb)