Elhub Specification of Nonconformity Files Version 1.3

Transcription

1 Elhub Specification of Nonconformity Files Version 1.3 Version Date

2 Contents 1 Introduction Change log About this document References Overview of nonconformity files Contract kontrakt Metering Point Målepunkt Metering Value Måleverdi Customer Kunde Description of technical format Filename convention Reading guide to detailed description of technical format Detailed description of technical format Contract Kontrakt SourcefileName MeteringPointUsed CustomerReferenceEndUser ValidFrom ValidTo FaultLevel FaultSeverity FaultCode FaultDueToValue FaultDescription Metering Point Målepunkt SourcefileName MeteringPointUsed ValidFrom ValidTo FaultLevel FaultSeverity FaultCode FaultDueToValue FaultDescription Customer Kunde SourcefileName CustomerReference ValidFrom ValidTo AddressType FaultLevel FaultSeverity FaultCode FaultDueToValue FaultDescription Metering value Måleverdi SourcefileName MeteringPointUsed TimeSeriesType ProductType Elhub Specification of Nonconformity Files Contents side 1

3 ProcessingDateTime StartDate EndDate FaultLevel FaultSeverity FaultCode FaultDueToValue FaultDescription Elhub Specification of Nonconformity Files Contents side 2

4 Table of figures Figure 1 Overview of nonconformity files... 6 Elhub Specification of Nonconformity Files Contents side 3

5 Table of tables Table 1 Filename convention... 8 Table 2 Reading guide to field descriptions... 9 Elhub Specification of Nonconformity Files Contents side 4

6 1 Introduction This document provides the technical specification of the nonconformity files that are generated by the Elhub Data Analysis and Migration tool as feedback to the Elhub Migration files as specified in [1]. 1.1 Change log Date Version Change Draft v0.1 First draft Draft v0.3 Added new content to chapters 4 and Draft v0.5 Updated accordingly to reflect the changes in v0.7 of Elhub specification of migration files Draft v0.9 Updated accordingly to reflect the changes in v0.9 of Elhub specification of migration files Draft v0.99 Added field "FaultDueTo" to files received by more than one market party Draft 1.1 Aligned format spec. with migration files V1.1b Aligned with same version of migration files, added field lengths for clarity V1.3 Added "FaultDueToValue" to MP and MV files. 1.2 About this document This document describes the content and format of the nonconformity files that are going to be returned to the market parties as a response to each migration file (described in Elhub Specification Of Migration Files ), containing deviations based on rule definitions residing in the Elhub Data And Migration tool(dam). 1.3 References 1. Elhub Specification of Migration Files 2. Elhub Specification of Migration Fault Codes 1 1 This document will be developed as part of the implementation project of the Elhub Migration Tool (DAM) Elhub Specification of Nonconformity Files side 5

7 2 Overview of nonconformity files This section describes the nonconformity files that will be used providing feedback to the market parties on their uploaded data. The nonconformity files match the migration files one on one, and they are illustrated in Figure 1 Overview of nonconformity files. Figure 1 Overview of nonconformity files 2.1 Contract kontrakt The Contract nonconformity file contains the response to the Contract migration file. A row in the Contract nonconformity file will contain the key attributes of the Contract migration file in addition to attributes describing an instance of a fault. There can be several faults per row of the Contract migration file. Each and every one of these faults is identified through a separate row in the Contract nonconformity file. A fault can either be syntactical or tied to a relation. All attributes, including key attributes, can be object to faults. An overview of all fault codes can be found in [2]. Key attributes of the Contract migration and nonconformity files are: MeteringPointUsed CustomerReferenceEndUser ValidFrom ValidTo 2.2 Metering Point Målepunkt The Metering Point nonconformity file contains the response to the Metering Point migration file. A row in the Metering Point nonconformity file will contain the key attributes of the Metering Point migration file in addition to attributes describing an instance of a fault. There can be several faults per row of the Metering Point migration file. Each and every one of these faults is identified through a separate row in the Metering Point nonconformity file. A fault can either be syntactical or tied to a relation. All attributes, including key attributes, can be object to faults. An overview of all fault codes can be found in [2]. Elhub Specification of Nonconformity Files side 6

8 Key attributes of the Metering Point migration and nonconformity files are: MeteringPointUsed ValidFrom ValidTo 2.3 Metering Value Måleverdi The Metering Value nonconformity file contains the response to the Metering Value migration file. A row in the Metering Value nonconformity file will contain the key attributes of the Metering Value migration file in addition to attributes describing an instance of a fault. There can be several faults per row of the Metering Value migration file. Each and every one of these faults is identified through a separate row in the Metering Value nonconformity file. A fault can either be syntactical or tied to a relation. All attributes, including key attributes, can be object to faults. An overview of all fault codes can be found in [2]. Key attributes of the Metering Value migration and nonconformity files are: MeteringPointUsed TimeSeriesType ProductType RegistrationDateTime StartDate EndDate 2.4 Customer Kunde The Customer nonconformity file contains the response to the Customer migration file. A row in the Customer nonconformity file will contain the key attributes of the Customer migration file in addition to attributes describing an instance of a fault. There can be several faults per row of the Customer migration file. Each and every one of these faults is identified through a separate row in the Customer nonconformity file. A fault can either be syntactical or tied to a relation. All attributes, including key attributes, can be object to faults. An overview of all fault codes can be found in [2]. Key attributes of the Customer migration and nonconformity files are: CustomerReference AddressType ValidFrom ValidTo Elhub Specification of Nonconformity Files side 7

9 3 Description of technical format Nonconformity files sent from Elhub will use the common UTF-8 codepage, and will follow a strict semicolon delimited format, containing the fields as mentioned in the following chapters. 3.1 Filename convention Table 1 Filename convention below describes the filename convention for the nonconformity files. Filepart name Role Organization number GLN Date File type Filepart syntax/value One of: BS, GO BS = Balance Supplier GO = Grid Owner Num(9) This is the official organization number as defined in Brønnøysundregistrene. Num(13) This is the GLN value defined for this organization and this role. Note, that a single organization may NOT use the same GLN for more than ONE role. If the organization acts as two different roles (BS and GO), it MUST also have or apply for two separate GLNs. YYYYDD One of: CO, MP, CUS, FORM, MV CO = Contract MP = Metering Point CUS = Customer FORM = Formula MV = Metering Value All of the above type specifications are suffixed with _NCF to identify the files as nonconformity files. Sequence number Num(3) starting at 001 Running sequence number used by this GLN within the same date, in case data Delimiter Dot (.) Suffix sdv (semicolon delimited file) Table 1 Filename convention The following is an example filename of a nonconformity file based on this convention: BS MP_NCF_01.sdv At present we have not defined any limit to the max size of any files. 3.2 Reading guide to detailed description of technical format Elhub Specification of Nonconformity Files side 8

10 Table 2 Reading guide to field descriptions explains the table which is used throughout this chapter for describing the various fields of the nonconformity files. [Name of the attribute] Table 2 Reading guide to field descriptions [Short name of the attribute] [Norwegian name of the attribute] [Textual description of the attribute.] [Type of data of the attribute, e.g., Enumeration, DateTime, Reference, etc.] [Specific format of the attribute, including size/length definition and numeric/text] [Example value of an instance of the attribute. The character ";" is NOT allowed in any value, and quotes ("")are NOT to be used for any value.] Note, that all lines will be terminated with CR+LF (0D0A, i.e., 0x0D followed by 0x0A). No non-print characters, including linefeed (0x0A) will be provided in any field (such as string fields). This also implies that the BOM character (Byte Order Mark, which would have the value of EFBBBF for UTF-8) often inserted in Unicode files, particularly from Microsoft sources, will not be present. 3.3 Detailed description of technical format Contract Kontrakt SourcefileName This is the name of the file in which this dataset was found to be containing the nonconformity. Later (updated) files with correct data will overwrite not only the dataset itself, but also the filename reference, thus ensuring that this field always points to the last (valid) version of the dataset. SourcefileName File Filnavn kilde Reference to the latest file containing the dataset having the nonconformity. Text(80) See filename specification BS CO_NCF_01.sdv Elhub Specification of Nonconformity Files side 9

11 MeteringPointUsed The MeteringPointUsed field is the main key in this file, containing the metering point ID for each specific record. The field may be equal for multiple rows, in which case all rows will represent different states (or historic values, as described in later fields/chapters) of the same metering point. MeteringPointUsed MP_Used MålepunktID Unique external reference to this metering point, which will be an accounting point. An accouting point is, according to the Elhub role and information model, the smallest entity under balance responsibility and/or where a change of supplier can take place. This can be a physical or logical point. GS1 GSRN Num(18) CustomerReferenceEndUser Note, this is the internal reference to a customer as used by the market party. Any connections across parties will, therefore and due to the lack of another unique identity, have to be made based on a metering point and corresponding to- and from dates. With this, it will be possible to relate the customer references between parties. Also, whenever the use of a public personal identification number is enforced in the market, this identity may be used as an alternative to this customer reference field or possibly only as a key to it through the customer file (depending on the sanctioned used of the public personal identity number for the energy sector). CustomerReferenceEndUser CusRefEndUsr Kundereferanse sluttbruker Unique reference to the Party connected to Grid which this information refers to. This reference is used to maintain relations across the import data. string(40) or numeric(40) Field length is dependent on the source system, and may be numeric or text, including (if used) UUID. 8fa7d500-2dbc-11e4-8c c9a ValidFrom This attribute describes the beginning of a new state of a Contract instance. For all attributes for which history is required, any change to any of these attributes will result in a change of state of the Contract instance. Elhub Specification of Nonconformity Files side 10

12 Note that the validity intervals specified by this (ValidFrom) and the next (ValidTo) fields, are to be read and interpreted as inclusive from, exclusive to - implying that the two intervals ( T14:00:00Z T15:00:00Z) and ( T15:00:00Z T16:00:00Z) are continuous across T15:00:00Z. The two intervals are to be read as ending before 15:00:00, and starting at 15:00:00 on the date specified. Thus, the same date will be allowed and accepted in the ValidTo field of the former record and the ValidFrom of the later record. ValidFrom ValidFrom Gyldig fra The datatime from when the dataset is valid. DateTime Value to be registered in UTC time with the format: YYYY--DDTHH::SSZ where: YYYY DD HH SS - year, four digits - month number, two digits - day of month, two digits - hour of day, 24 hour format, two digits - minute of hour, two digits - second of minute, two digits, usually set to 00, unless specific interval is required T09:04:45Z ValidTo This attribute describes the end of a state of a Contract instance. For all attributes for which history is required, any change to any of these attributes will result in a change of state of the Contract instance. ValidTo ValidTo Gyldig til The datatime until which point the dataset was valid. If last, i.e., still valid, this field shall be left blank. DateTime Value to be registered in UTC time with the format: YYYY--DDTHH::SSZ where: YYYY DD HH - year, four digits - month number, two digits - day of month, two digits - hour of day, 24 hour format, two digits - minute of hour, two digits Elhub Specification of Nonconformity Files side 11

13 SS - second of minute, two digits, usually set to 00, unless specific interval is required FaultLevel This field indicates at what point in the processing that the nonconformity was discovered. This value will be defined at the level of the controlling rule which may be offended. As such, the level may be one of Syntax, Relation or Consistency. - Syntax deviations include data formats and other data type- or format errors, and are typically evaluated on single fields. - Relation deviations include any correlations which must be maintained across multiple fields, either within the same file or across multiple files within the same package, i.e., from the same market parties. - Consistency deviations are checks on values across different market parties. FaultLevel FaultLvl AvviksNivå Level of deviation, describing the level which contains the rule that found the fault. Integer 1 = Syntax 2 = Relation 3 = Consistency FaultSeverity This field corresponds to the quality assurance requirements defined for fields in the migration files. Thus, the severity and quality assurance correlations stated in the table below will be enforced. Reports on different severities also depend on the FaultLevel, as described in the following table: FaultLevel FaultSeverity Triggering market party Nonconformity file to 1 - Syntax Any Any Same party 2 - Relation Any Any Same party 3 - Consistency 1 - Critical Any Both parties 3 - Consistency 2 - Significant Any Balance Supplier 3 - Consistency 3 - Minor Any Balance Supplier Following data quality reviews, if the triggering market party finds that its own data is most likely correct and that the other market party must change its data, this must be handled bilaterally between the parties. In these cases, the Elhub migration project will not participate in data corrections, and will only assume that data will be adjusted according to market needs. Elhub Specification of Nonconformity Files side 12

14 As a last line approach and if data is still not consistent at Elhub go-live (be it end user names, addresses or other non-reconcilable data), the Grid Access Provider will be used as the default master data source. Thus, if the Balance Supplier needs to persist its data, this must be handled bilaterally with the GAP, so that the latter also changes its data in accordance with agreed data values. FaultSeverity FaultSeverity Avvikskritikalitet Severity level of the deviation, depending on the reule that was triggered on a particular fault. Integer 1 = Critical nonconformity, must be corrected. Corresponds to a Required quality assurance level. 2 = Significant nonconformity, should be corrected. Corresponds to a Recommended quality assurance level. 3 = Minor nonconformity, may be corrected. If not corrected, it may be overwritten by datasets from another market party or the deviation will be ignored in Elhub. This level corresponds to a Suggested quality assurance level FaultCode This field is a unique reference to the offended rule. As such, a separate list of rules and descriptions, including the fields involved in this rule is (will be made) available from the Elhub migration project [2]. This list, as well as its related codes will be developed through iterations as new nonconformities are discovered, and their resolutions are implemented as automatic controls. FaultCode FaultCode Avvikskode Unique code for the fault, consisting of a prefix EMF (Elhub Migration Fault), the fault level and a unique number. Text(8) EMF + [FaultLevel] + [Unique number between 1 and 9999] In special cases we might use the fault code that ends with a 0 e.g. EMF10000, EMF20000 and EMF See fault description for how this is implemented. EMF30009 (FaultLevel is 3 = Consistency with unique number 0009) FaultDueToValue This field contains the value that triggered the nonconformity condition. For consistency checks, the field might contain the value from the opposite market party that triggered the fault. This will be indicated in FaultDescription. The opposite market party must be retrieved from the relation on the metering point. FaultDueToValue FaultValue Elhub Specification of Nonconformity Files side 13

15 Feil grunnet verdi The value that triggered the fault. If appropriate and relevant, the actual value from another market party triggering a nonconformity condition. string(150) Text(150) FaultDescription Whenever the fault code may not be set to a specific rule, i.e., the rule may not have been defined (yet) or the fault is of such a complexity and/or rarity that it will not be implemented as an automated control, this field will be used for providing a short description of the nonconformity condition. Thus, for some rare or complex situation, this field may be reused for the same conditions, while if a case has just been detected and not yet implemented as a separate (automated) rule, this field will be used. In the latter case, the use of this field will disappear as new fault codes are introduced for an initially unknown case. FaultDescription FaultDesc Feilbeskrivelse This field is only to be used in special cases where the reason or source is inconclusive, and where the other defined fault codes are insufficient. NB! It will always be used in conjunction with fault codes that end with 0. e.g EMF10000, EMF200000, EMF If FaultCode ends with 0, the field is considered NA. string(150) Text(150) "Inconsisteny found when matching customer address with other market party" Metering Point Målepunkt SourcefileName This is the name of the file in which this dataset was found to be containing the nonconformity. Later (updated) files with correct data will overwrite not only the dataset itself, but also the filename reference, thus ensuring that this field always points to the last (valid) version of the dataset. SourcefileName File Filnavn kilde Elhub Specification of Nonconformity Files side 14

16 Reference to the latest file containing the dataset having the nonconformity. Text(80) See filename specification BS MP_NCF_01.sdv MeteringPointUsed MeteringPointUsed MP_Used MålepunktID Unique external reference to this metering point, which will be an accounting point. An accouting point is, according to the Elhub role and information model, the smallest entity under balance responsibility and/or where a change of supplier can take place. This can be a physical or logical point. GS1 GSRN Num(18) ValidFrom This attribute describes the beginning of a new state of a Contract instance. For all attributes for which history is required, any change to any of these attributes will result in a change of state of the Contract instance. Note that the validity intervals specified by this (ValidFrom) and the next (ValidTo) fields, are to be read and interpreted as inclusive from, exclusive to - implying that the two intervals ( T14:00:00Z T15:00:00Z) and ( T15:00:00Z T16:00:00Z) are continuous across T15:00:00Z. The two intervals are to be read as ending before 15:00:00, and starting at 15:00:00 on the date specified. Thus, the same date will be allowed and accepted in the ValidTo field of the former record and the ValidFrom of the later record. ValidFrom ValidFrom Gyldig fra The datatime from when the dataset is valid. DateTime Value to be registered in UTC time with the format: YYYY--DDTHH::SSZ where: YYYY DD - year, four digits - month number, two digits - day of month, two digits Elhub Specification of Nonconformity Files side 15

17 HH SS - hour of day, 24 hour format, two digits - minute of hour, two digits - second of minute, two digits, usually set to 00, unless specific interval is required T09:04:45Z ValidTo This attribute describes the end of a state of a Contract instance. For all attributes for which history is required, any change to any of these attributes will result in a change of state of the Contract instance. ValidTo ValidTo Gyldig til The datatime until which point the dataset was valid. If last, i.e., still valid, this field shall be left blank. DateTime Value to be registered in UTC time with the format: YYYY--DDTHH::SSZ where: YYYY DD HH SS - year, four digits - month number, two digits - day of month, two digits - hour of day, 24 hour format, two digits - minute of hour, two digits - second of minute, two digits, usually set to 00, unless specific interval is required FaultLevel This field indicates at what point in the processing that the nonconformity was discovered. This value will be defined at the level of the controlling rule which may be offended. As such, the level may be one of Syntax, Relation or Consistency. - Syntax deviations include data formats and other data type- or format errors, and are typically evaluated on single fields. - Relation deviations include any correlations which must be maintained across multiple fields, either within the same file or across multiple files within the same package, i.e., from the same market parties. - Consistency deviations are checks on values across different market parties. FaultLevel Elhub Specification of Nonconformity Files side 16

18 FaultLvl AvviksNivå Level of deviation, describing the level which contains the rule that found the fault. Integer 1 = Syntax 2 = Relation 3 = Consistency FaultSeverity This field corresponds to the quality assurance requirements defined for fields in the migration files. However, since the Grid Access Provider is the sole provider of such files, this party needs to correct any nonconformities in its own data prior to Elhub go-live. FaultSeverity FaultSeverity Avvikskritikalitet Severity level of the deviation, depending on the reule that was triggered on a particular fault. Integer 1 = Critical nonconformity, must be corrected. Corresponds to a Required quality assurance level. 2 = Significant nonconformity, should be corrected. Corresponds to a Recommended quality assurance level. 3 = Minor nonconformity, may be corrected. If not corrected, it may be overwritten by datasets from another market party or the deviation will be ignored in Elhub. This level corresponds to a Suggested quality assurance level FaultCode This field is a unique reference to the offended rule. As such, a separate list of rules and descriptions, including the fields involved in this rule is (will be made) available from the Elhub migration project [2]. This list, as well as its related codes will be developed through iterations as new nonconformities are discovered, and their resolutions are implemented as automatic controls. FaultCode FaultCode Avvikskode Unique code for the fault, consisting of a prefix EMF (Elhub Migration Fault), the fault level and a unique number. Text(8) EMF + [FaultLevel] + [Unique number between 1 and 9999] Elhub Specification of Nonconformity Files side 17

19 In special cases we might use the fault code that ends with a 0 e.g. EMF10000, EMF20000 and EMF See fault description for how this is implemented. EMF30009 (FaultLevel is 3 = Consistency with unique number 0009) FaultDueToValue This field contains the value that triggered the nonconformity condition. For consistency checks, the field might contain the value from the opposite market party that triggered the fault. This will be indicated in FaultDescription. The opposite market party must be retrieved from the relation on the metering point. FaultDueToValue FaultValue Feil grunnet verdi The value that triggered the fault. If appropriate and relevant, the actual value from another market party triggering a nonconformity condition. string(150) Text(150) FaultDescription Whenever the fault code may not be set to a specific rule, i.e., the rule may not have been defined (yet) or the fault is of such a complexity and/or rarity that it will not be implemented as an automated control, this field will be used for providing a short description of the nonconformity condition. Thus, for some rare or complex situation, this field may be reused for the same conditions, while if a case has just been detected and not yet implemented as a separate (automated) rule, this field will be used. In the latter case, the use of this field will disappear as new fault codes are introduced for an initially unknown case. Short name: Norwegian name: FaultDescription FaultDesc Feilbeskrivelse This field is only to be used in special cases where the reason or source is inconclusive, and where the other defined fault codes are insufficient. NB! It will always be used in conjunction with fault codes that end with 0. e.g EMF10000, EMF200000, EMF If FaultCode ends with 0, the field is considered NA. string(150) Text(150) Elhub Specification of Nonconformity Files side 18

20 "Inconsisteny found when matching customer address with other market party" Customer Kunde SourcefileName This is the name of the file in which this dataset was found to be containing the nonconformity. Later (updated) files with correct data will overwrite not only the dataset itself, but also the filename reference, thus ensuring that this field always points to the last (valid) version of the dataset. SourcefileName File Filnavn kilde Reference to the latest file containing the dataset having the nonconformity. Text(80) See filename specification BS CUS_NCF_01.sdv CustomerReference Note, this is the internal reference to a customer (or invoice address) as used by the market party. Any connections across parties will, therefore and due to the lack of another unique identity, have to be made based on a metering point and corresponding to- and from dates. With this, it will be possible to relate the customer references between parties. Also, whenever the use of a public personal identification number is enforced in the market, this identity may be used as an alternative to this customer reference field or possibly only as a key to it through the customer file (depending on the sanctioned used of the public personal identity number for the energy sector). CustomerReference CusRef Kundereferanse Unique reference to the Party connected to Grid which this information refers to. This reference is used to maintain relations across the import data. Reference E.g UUID 8fa7d500-2dbc-11e4-8c c9a ValidFrom Elhub Specification of Nonconformity Files side 19

21 This attribute describes the beginning of a new state of a Contract instance. For all attributes for which history is required, any change to any of these attributes will result in a change of state of the Contract instance. Note that the validity intervals specified by this (ValidFrom) and the next (ValidTo) fields, are to be read and interpreted as inclusive from, exclusive to - implying that the two intervals ( T14:00:00Z T15:00:00Z) and ( T15:00:00Z T16:00:00Z) are continuous across T15:00:00Z. The two intervals are to be read as ending before 15:00:00, and starting at 15:00:00 on the date specified. Thus, the same date will be allowed and accepted in the ValidTo field of the former record and the ValidFrom of the later record. ValidFrom ValidFrom Gyldig fra The datatime from when the dataset is valid. DateTime Value to be registered in UTC time with the format: YYYY--DDTHH::SSZ where: YYYY DD HH SS - year, four digits - month number, two digits - day of month, two digits - hour of day, 24 hour format, two digits - minute of hour, two digits - second of minute, two digits, usually set to 00, unless specific interval is required T09:04:45Z ValidTo This attribute describes the end of a state of a Contract instance. For all attributes for which history is required, any change to any of these attributes will result in a change of state of the Contract instance. ValidTo ValidTo Gyldig til The datatime until which point the dataset was valid. If last, i.e., still valid, this field shall be left blank. DateTime Value to be registered in UTC time with the format: YYYY--DDTHH::SSZ where: YYYY - year, four digits Elhub Specification of Nonconformity Files side 20

22 DD HH SS - month number, two digits - day of month, two digits - hour of day, 24 hour format, two digits - minute of hour, two digits - second of minute, two digits, usually set to 00, unless specific interval is required AddressType Values AddressType AdrType AdresseType Type of address information in this record; If this is a address for invoicing or to the end user AddressTypeEnumeration Invoice EndUser EndUser FaultLevel This field indicates at what point in the processing that the nonconformity was discovered. This value will be defined at the level of the controlling rule which may be offended. As such, the level may be one of Syntax, Relation or Consistency. - Syntax deviations include data formats and other data type- or format errors, and are typically evaluated on single fields. - Relation deviations include any correlations which must be maintained across multiple fields, either within the same file or across multiple files within the same package, i.e., from the same market parties. - Consistency deviations are checks on values across different market parties. FaultLevel FaultLvl AvviksNivå Level of deviation, describing the level which contains the rule that found the fault. Integer 1 = Syntax 2 = Relation 3 = Consistency 1 Elhub Specification of Nonconformity Files side 21

23 FaultSeverity This field corresponds to the quality assurance requirements defined for fields in the migration files. Thus, the severity and quality assurance correlations stated in the table below will be enforced. Reports on different severities also depend on the FaultLevel, as described in the following table: FaultLevel FaultSeverity Triggering market party Nonconformity file to 1 - Syntax Any Any Same party 2 - Relation Any Any Same party 3 - Consistency 1 - Critical Any Both parties 3 - Consistency 2 - Significant Any Balance Supplier 3 - Consistency 3 - Minor Any Balance Supplier Following data quality reviews, if the triggering market party finds that its own data is most likely correct and that the other market party must change its data, this must be handled bilaterally between the parties. In these cases, the Elhub migration project will not participate in data corrections, and will only assume that data will be adjusted according to market needs. As a last line approach and if data is still not consistent at Elhub go-live (be it end user names, addresses or other non-reconcilable data), the Grid Access Provider will be used as the default master data source. Thus, if the Balance Supplier needs to persist its data, this must be handled bilaterally with the GAP, so that the latter also changes its data in accordance with agreed data values. FaultSeverity FaultSeverity Avvikskritikalitet Severity level of the deviation, depending on the reule that was triggered on a particular fault. Integer 1 = Critical nonconformity, must be corrected. Corresponds to a Required quality assurance level. 2 = Significant nonconformity, should be corrected. Corresponds to a Recommended quality assurance level. 3 = Minor nonconformity, may be corrected. If not corrected, it may be overwritten by datasets from another market party or the deviation will be ignored in Elhub. This level corresponds to a Suggested quality assurance level FaultCode This field is a unique reference to the offended rule. As such, a separate list of rules and descriptions, including the fields involved in this rule is (will be made) available from the Elhub migration project [2]. This list, as well as its related codes will be developed through iterations as new nonconformities are discovered, and their resolutions are implemented as automatic controls. FaultCode Elhub Specification of Nonconformity Files side 22

24 FaultCode Avvikskode Unique code for the fault, consisting of a prefix EMF (Elhub Migration Fault), the fault level and a unique number. Text(8) EMF + [FaultLevel] + [Unique number between 1 and 9999] In special cases we might use the fault code that ends with a 0 e.g. EMF10000, EMF20000 and EMF See fault description for how this is implemented. EMF30009 (FaultLevel is 3 = Consistency with unique number 0009) FaultDueToValue This field contains the value that triggered the nonconformity condition. For consistency checks, the field might contain the value from the opposite market party that triggered the fault. This will be indicated in FaultDescription. The opposite market party must be retrieved from the relation on the metering point. FaultDueToValue FaultValue Feil grunnet verdi The value that triggered the fault. If appropriate and relevant, the actual value from another market party triggering a nonconformity condition. string(150) Text(150) FaultDescription Whenever the fault code may not be set to a specific rule, i.e., the rule may not have been defined (yet) or the fault is of such a complexity and/or rarity that it will not be implemented as an automated control, this field will be used for providing a short description of the nonconformity condition. Thus, for some rare or complex situation, this field may be reused for the same conditions, while if a case has just been detected and not yet implemented as a separate (automated) rule, this field will be used. In the latter case, the use of this field will disappear as new fault codes are introduced for an initially unknown case. Short name: Norwegian name: FaultDescription FaultDesc Feilbeskrivelse This field is only to be used in special cases where the reason or source is inconclusive, and where the other defined fault codes are insufficient. Elhub Specification of Nonconformity Files side 23

25 NB! It will always be used in conjunction with fault codes that end with 0. e.g EMF10000, EMF200000, EMF If FaultCode ends with 0, the field is considered NA. string(150) Text(150) "Inconsisteny found when matching customer address with other market party" Metering value Måleverdi SourcefileName This is the name of the file in which this dataset was found to be containing the nonconformity. Later (updated) files with correct data will overwrite not only the dataset itself, but also the filename reference, thus ensuring that this field always points to the last (valid) version of the dataset. SourcefileName File Filnavn kilde Reference to the latest file containing the dataset having the nonconformity. Text(80) See filename specification BS MV_NCF_01.sdv MeteringPointUsed MeteringPointUsed MP_Used MålepunktID Unique external reference to this metering point, which will be an accounting point. An accouting point is, according to the Elhub role and information model, the smallest entity under balance responsibility and/or where a change of supplier can take place. This can be a physical or logical point. GS1 GSRN Num(18) TimeSeriesType TimeSeriesType Elhub Specification of Nonconformity Files side 24

26 Values: TS_Type Tidsserie type Type of time series of the metered values. This may be production (E18) or consumption (E17), and identifies the energy direction of this time series. TimeSeriesTypeEnumeration E17 = Out E18 = In E ProductType ProductType TS_SubType Produktkode Type of time series or product of the metered values. This may be active or reactive energy - according to the given code sets. ProductTypeEnumeration Values: = Energy Active = Energy Reactive ProcessingDateTime ProcDateTime RegDate Prosesseringstidspunkt for tidsserie Date and time when a value was registered in the grid operators system. ISO 8601 Dato/tid, UTC. DateTime Value to be registered in UTC time with the format: YYYY--DDTHH::SSZ where: YYYY DD HH SS - year, four digits - month number, two digits - day of month, two digits - hour of day, 24 hour format, two digits - minute of hour, two digits - second of minute, two digits, usually set to 00, unless specific interval is required T03:00:00Z StartDate Elhub Specification of Nonconformity Files side 25

27 Note that the validity intervals specified by this (StartDate) and the next (EndDate) fields are to be read and interpreted as inclusive from, exclusive to - implying that the two intervals ( T14:00:00Z T15:00:00Z) and ( T15:00:00Z T16:00:00Z) are continuous across T15:00:00Z. The two intervals are to be read as ending before 15:00:00, and starting at 15:00:00 on the date specified. Thus, the same date will be allowed and accepted in the EndDate field of the former record and the StartDate of the later record. StartDate Start Start av tidsperiode Start of the validity datetime for the value. DateTime Value to be registered in UTC time with the format: YYYY--DDTHH::SSZ where: YYYY DD HH SS - year, four digits - month number, two digits - day of month, two digits - hour of day, 24 hour format, two digits - minute of hour, two digits - second of minute, two digits, usually set to 00, unless specific interval is required T03:00:00Z EndDate EndDate End Slutt av tidsperiode End of the validity datetime of the value DateTime Value to be registered in UTC time with the format: YYYY--DDTHH::SSZ where: YYYY DD HH SS - year, four digits - month number, two digits - day of month, two digits - hour of day, 24 hour format, two digits - minute of hour, two digits - second of minute, two digits, usually set to 00, unless specific interval is required T03:00:00Z Elhub Specification of Nonconformity Files side 26

28 FaultLevel This field indicates at what point in the processing that the nonconformity was discovered. This value will be defined at the level of the controlling rule which may be offended. As such, the level may be one of Syntax, Relation or Consistency. - Syntax deviations include data formats and other data type- or format errors, and are typically evaluated on single fields. - Relation deviations include any correlations which must be maintained across multiple fields, either within the same file or across multiple files within the same package, i.e., from the same market parties. - Consistency deviations are checks on values across different market parties. FaultLevel FaultLvl AvviksNivå Level of deviation, describing the level which contains the rule that found the fault. Integer 1 = Syntax 2 = Relation 3 = Consistency FaultSeverity This field corresponds to the quality assurance requirements defined for fields in the migration files. However, since the Grid Access Provider is the sole provider of such files, this party needs to correct any nonconformities in its own data prior to Elhub go-live. FaultSeverity FaultSeverity Avvikskritikalitet Severity level of the deviation, depending on the reule that was triggered on a particular fault. Integer 1 = Critical nonconformity, must be corrected. Corresponds to a Required quality assurance level. 2 = Significant nonconformity, should be corrected. Corresponds to a Recommended quality assurance level. 3 = Minor nonconformity, may be corrected. If not corrected, it may be overwritten by datasets from another market party or the deviation will be ignored in Elhub. This level corresponds to a Suggested quality assurance level. 1 Elhub Specification of Nonconformity Files side 27

29 FaultCode This field is a unique reference to the offended rule. As such, a separate list of rules and descriptions, including the fields involved in this rule is (will be made) available from the Elhub migration project [2]. This list, as well as its related codes will be developed through iterations as new nonconformities are discovered, and their resolutions are implemented as automatic controls. FaultCode FaultCode Avvikskode Unique code for the fault, consisting of a prefix EMF (Elhub Migration Fault), the fault level and a unique number. Text(8) EMF + [FaultLevel] + [Unique number between 1 and 9999] In special cases we might use the fault code that ends with a 0 e.g. EMF10000, EMF20000 and EMF See fault description for how this is implemented. EMF30009 (FaultLevel is 3 = Consistency with unique number 0009) FaultDueToValue This field contains the value that triggered the nonconformity condition. The opposite market party must be retrieved from the relation on the metering point. FaultDueToValue FaultValue Feil grunnet Verdi The value that triggered the fault. string(150) Text(150) FaultDescription Whenever the fault code may not be set to a specific rule, i.e., the rule may not have been defined (yet) or the fault is of such a complexity and/or rarity that it will not be implemented as an automated control, this field will be used for providing a short description of the nonconformity condition. Thus, for some rare or complex situation, this field may be reused for the same conditions, while if a case has just been detected and not yet implemented as a separate (automated) rule, this field will be used. In the latter case, the use of this field will disappear as new fault codes are introduced for an initially unknown case. Short name: Norwegian name: FaultDescription FaultDesc Feilbeskrivelse Elhub Specification of Nonconformity Files side 28

30 This field is only to be used in special cases where the reason or source is inconclusive, and where the other defined fault codes are insufficient. NB! It will always be used in conjunction with fault codes that end with 0. e.g EMF10000, EMF200000, EMF If FaultCode ends with 0, the field is considered NA. string(150) Text(150) "Inconsisteny found when matching customer address with other market party" Elhub Specification of Nonconformity Files side 29