Elhub Specification of
Nonconformity Files
Version 1.1b
Version
1.1b
Date
24.11.2015
Contents
1
Introduction ..................................................................................................................................... 5
1.1 Change log .................................................................................................................................. 5
1.2 About this document.................................................................................................................. 5
1.3 References .................................................................................................................................. 5
2
Overview of nonconformity files ..................................................................................................... 6
2.1 Contract – kontrakt .................................................................................................................... 6
2.2 Metering Point – Målepunkt ...................................................................................................... 6
2.3 Metering Value – Måleverdi....................................................................................................... 7
2.4 Customer – Kunde ...................................................................................................................... 7
3
Description of technical format....................................................................................................... 8
3.1 Filename convention .................................................................................................................. 8
3.2 Reading guide to detailed description of technical format........................................................ 8
3.3 Detailed description of technical format ................................................................................... 9
3.3.1
Contract – Kontrakt ........................................................................................................... 9
3.3.1.1
3.3.1.2
3.3.1.3
3.3.1.4
3.3.1.5
3.3.1.6
3.3.1.7
3.3.1.8
3.3.1.9
3.3.1.10
3.3.2
Metering Point – Målepunkt ........................................................................................... 14
3.3.2.1
3.3.2.2
3.3.2.3
3.3.2.4
3.3.2.5
3.3.2.6
3.3.2.7
3.3.2.8
3.3.3
SourcefileName ........................................................................................................................................ 14
MeteringPointUsed ................................................................................................................................... 15
ValidFrom................................................................................................................................................. 15
ValidTo ..................................................................................................................................................... 16
FaultLevel ................................................................................................................................................. 16
FaultSeverity............................................................................................................................................. 17
FaultCode ................................................................................................................................................. 17
FaultDescription ....................................................................................................................................... 18
Customer – Kunde ........................................................................................................... 18
3.3.3.1
3.3.3.2
3.3.3.3
3.3.3.4
3.3.3.5
3.3.3.6
3.3.3.7
3.3.3.8
3.3.3.9
3.3.3.10
3.3.4
SourcefileName .......................................................................................................................................... 9
MeteringPointUsed ................................................................................................................................... 10
CustomerReferenceEndUser ..................................................................................................................... 10
ValidFrom................................................................................................................................................. 10
ValidTo ..................................................................................................................................................... 11
FaultLevel ................................................................................................................................................. 12
FaultSeverity............................................................................................................................................. 12
FaultCode ................................................................................................................................................. 13
FaultDueToValue ..................................................................................................................................... 13
FaultDescription .................................................................................................................................. 14
SourcefileName ........................................................................................................................................ 18
CustomerReference................................................................................................................................... 19
ValidFrom................................................................................................................................................. 19
ValidTo ..................................................................................................................................................... 20
AddressType ............................................................................................................................................. 20
FaultLevel ................................................................................................................................................. 21
FaultSeverity............................................................................................................................................. 21
FaultCode ................................................................................................................................................. 22
FaultDueToValue ..................................................................................................................................... 22
FaultDescription .................................................................................................................................. 23
Metering value – Måleverdi ............................................................................................ 23
3.3.4.1
3.3.4.2
3.3.4.3
3.3.4.4
3.3.4.5
SourcefileName ........................................................................................................................................ 23
MeteringPointUsed ................................................................................................................................... 24
TimeSeriesType ........................................................................................................................................ 24
ProductType.............................................................................................................................................. 24
ProcessingDateTime ................................................................................................................................. 25
Elhub Specification of Nonconformity Files ● Contents
side 1
3.3.4.6
3.3.4.7
3.3.4.8
3.3.4.9
3.3.4.10
3.3.4.11
StartDate ................................................................................................................................................... 25
EndDate .................................................................................................................................................... 26
FaultLevel ................................................................................................................................................. 26
FaultSeverity............................................................................................................................................. 27
FaultCode ............................................................................................................................................ 27
FaultDescription .................................................................................................................................. 27
Elhub Specification of Nonconformity Files ● Contents
side 2
Table of figures
Figure 2 Overview of nonconformity files ............................................................................................... 6
Elhub Specification of Nonconformity Files ● Contents
side 3
Table of tables
Table 1 Filename convention .................................................................................................................. 8
Table 2 Reading guide to field descriptions ............................................................................................ 9
Elhub Specification of Nonconformity Files ● Contents
side 4
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
30.06.2014
Draft v0.1
First draft
01.09.2014
Draft v0.3
Added new content to chapters 4 and 6.
18.12.2014
Draft v0.5
22.01.2015
Draft v0.9
10.04.2015
Draft v0.99
26.10.2015
Draft 1.1
24.11.2015
V1.1b
Updated accordingly to reflect the changes in v0.7 of
“Elhub specification of migration files”
Updated accordingly to reflect the changes in v0.9 of
“Elhub specification of migration files”
Added field "FaultDueTo" to files received by more than
one market party.
Aligned format spec. with migration files.
Aligned with same version of migration files, added field
lengths for clarity.
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
1.
Elhub Specification of Migration Files
2.
Elhub Specification of Migration Fault Codes1
This document will be developed as part of the implementation project of the Elhub Migration Tool (DAM)
Elhub Specification of Nonconformity Files
side 5
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
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
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.
YYYYMMDD
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
Delimiter
Suffix
Num(3) starting at 001
Running sequence number used by this GLN within the same
date, in case data
Dot (.)
sdv (semicolon delimited file)
Table 1 Filename convention
The following is an example filename of a nonconformity file based on this convention:

BS-999999999-0123456789012-20140919-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
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:
[Name of the attribute]
Short name:
[Short name of the attribute]
Norwegian name:
[Norwegian name of the attribute]
Description:
[Textual description of the attribute.]
Type:
[Type of data of the attribute, e.g., Enumeration, DateTime, Reference,
etc.]
Format:
[Specific format of the attribute, including size/length definition and
numeric/text]
Example:
[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.]
Table 2 Reading guide to field descriptions
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
3.3.1 Contract – Kontrakt
3.3.1.1
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.
Name:
Short name:
Norwegian name:
Description:
Type:
Format:
Example:
Elhub Specification of Nonconformity Files
SourcefileName
File
Filnavn kilde
Reference to the latest file containing the dataset having the
nonconformity.
Text(80)
See filename specification
BS-999999999-0123456789012-20140919-CO_NCF_01.sdv
side 9
3.3.1.2
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.
Name:
Short name:
Norwegian name:
Description:
Type:
Format:
Example:
3.3.1.3
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)
707057500054119000
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).
Name:
Short name:
Norwegian name:
Description:
Type:
Format:
Example:
3.3.1.4
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-8c21-0800200c9a66
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
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 (2014-1223T14:00:00Z - 2014-12-23T15:00:00Z) and (2014-12-23T15:00:00Z - 2014-12-23T16:00:00Z) are
continuous across 2014-12-23T15: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.
Name:
Short name:
Norwegian name:
Description:
Type:
Format:
ValidFrom
ValidFrom
Gyldig fra
The datatime from when the dataset is valid.
DateTime
Value to be registered in UTC time with the format:
YYYY-MM-DDTHH:MM:SSZ
where:
YYYY
MM
DD
HH
MM
SS
Example:
- 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.
2014-03-10T09:04:45Z
3.3.1.5 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.
Name:
Short name:
Norwegian name:
Description:
Type:
Format:
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-MM-DDTHH:MM:SSZ
where:
YYYY
MM
DD
HH
MM
Elhub Specification of Nonconformity Files
- 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
side 11
SS
3.3.1.6
- 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.
Name:
Short name:
Norwegian name:
Description:
Type:
Format:
Example:
3.3.1.7
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
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
1 - Syntax
2 - Relation
3 - Consistency
3 - Consistency
3 - Consistency
FaultSeverity
Any
Any
1 - Critical
2 - Significant
3 - Minor
Triggering market party
Any
Any
Any
Any
Any
Nonconformity file to
Same party
Same party
Both parties
Balance Supplier
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
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.
Name:
Short name:
Norwegian name:
Description:
Type:
Format:
Example:
3.3.1.8
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
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.
Name:
Short name:
Norwegian name:
Description:
Type:
Format:
Example:
3.3.1.9
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 EMF30000. See fault description
for how this is implemented.
EMF30009 (FaultLevel is 3 = Consistency with unique number
0009)
FaultDueToValue
This field contains the value from another market party which triggered the nonconformity
condition. The opposite market party must be retrieved from the relation on the metering point.
Name:
Short name:
Norwegian name:
Elhub Specification of Nonconformity Files
FaultDueToValue
FaultValue
Feil grunnet verdi
side 13
Description:
Type:
Format:
Example:
If appropriate and relevant, the actual value from another market
party triggering a nonconformity condition.
string(150)
Text(150)
61015812345
3.3.1.10 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.
Name:
Short name:
Norwegian name:
Description:
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, EMF300000
Type:
Format:
Example:
If FaultCode ends with 0, the field is considered NA.
string(150)
Text(150)
"Inconsisteny found when matching customer address with other
market party"
3.3.2 Metering Point – Målepunkt
3.3.2.1
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.
Name:
Short name:
Norwegian name:
Description:
Elhub Specification of Nonconformity Files
SourcefileName
File
Filnavn kilde
Reference to the latest file containing the dataset having the
nonconformity.
side 14
Type:
Format:
Example:
3.3.2.2
MeteringPointUsed
Name:
Short name:
Norwegian name:
Description:
Type:
Format:
Example:
3.3.2.3
Text(80)
See filename specification
BS-999999999-0123456789012-20140919-MP_NCF_01.sdv
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)
707057500054119000
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 (2014-1223T14:00:00Z - 2014-12-23T15:00:00Z) and (2014-12-23T15:00:00Z - 2014-12-23T16:00:00Z) are
continuous across 2014-12-23T15: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.
Name:
Short name:
Norwegian name:
Description:
Type:
Format:
ValidFrom
ValidFrom
Gyldig fra
The datatime from when the dataset is valid.
DateTime
Value to be registered in UTC time with the format:
YYYY-MM-DDTHH:MM:SSZ
where:
YYYY
MM
DD
HH
MM
Elhub Specification of Nonconformity Files
- 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
side 15
SS
Example:
3.3.2.4
- second of minute, two digits, usually set to
00, unless
specific interval is
required.
2014-03-10T09: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.
Name:
Short name:
Norwegian name:
Description:
Type:
Format:
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-MM-DDTHH:MM:SSZ
where:
YYYY
MM
DD
HH
MM
SS
3.3.2.5
- 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.
Name:
Short name:
Norwegian name:
Elhub Specification of Nonconformity Files
FaultLevel
FaultLvl
AvviksNivå
side 16
Description:
Type:
Format:
Example:
3.3.2.6
Level of deviation, describing the level which contains the rule
that found the fault.
Integer
1 = Syntax
2 = Relation
3 = Consistency
1
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.
Name:
Short name:
Norwegian name:
Description:
Type:
Format:
Example:
3.3.2.7
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
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.
Name:
Short name:
Norwegian name:
Description:
Type:
Format:
Elhub Specification of Nonconformity Files
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 EMF30000. See fault description
for how this is implemented.
side 17
Example:
3.3.2.8
EMF30009 (FaultLevel is 3 = Consistency with unique number
0009)
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.
Name:
Short
name:
Norwegian
name:
Description:
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, EMF300000
Type:
Format:
Example:
If FaultCode ends with 0, the field is considered NA.
string(150)
Text(150)
"Inconsisteny found when matching customer address with other
market party"
3.3.3 Customer – Kunde
3.3.3.1
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.
Name:
Short name:
Norwegian name:
Description:
Type:
Elhub Specification of Nonconformity Files
SourcefileName
File
Filnavn kilde
Reference to the latest file containing the dataset having the
nonconformity.
Text(80)
side 18
Format:
Example:
3.3.3.2
See filename specification
BS-999999999-0123456789012-20140919-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).
Name:
Short name:
Norwegian name:
Description:
Type:
Format:
Example:
3.3.3.3
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-8c21-0800200c9a66
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 (2014-1223T14:00:00Z - 2014-12-23T15:00:00Z) and (2014-12-23T15:00:00Z - 2014-12-23T16:00:00Z) are
continuous across 2014-12-23T15: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.
Name:
Short name:
Norwegian name:
Description:
Type:
Format:
ValidFrom
ValidFrom
Gyldig fra
The datatime from when the dataset is valid.
DateTime
Value to be registered in UTC time with the format:
YYYY-MM-DDTHH:MM:SSZ
where:
YYYY
MM
Elhub Specification of Nonconformity Files
- year, four digits
- month number, two digits
side 19
DD
HH
MM
SS
Example:
- 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.
2014-03-10T09:04:45Z
3.3.3.4 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.
Name:
Short name:
Norwegian name:
Description:
Type:
Format:
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-MM-DDTHH:MM:SSZ
where:
YYYY
MM
DD
HH
MM
SS
3.3.3.5
- 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.
AddressType
Name:
AddressType
Short name:
AdrType
Norwegian name:
AdresseType
Description:
Type of address information in this record; If this is a address for invoicing
or to the end user
Type:
AddressTypeEnumeration
Values
Invoice
EndUser
Example:
EndUser
Elhub Specification of Nonconformity Files
side 20
3.3.3.6
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.
Name:
Short name:
Norwegian name:
Description:
Type:
Format:
Example:
3.3.3.7
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
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
1 - Syntax
2 - Relation
3 - Consistency
3 - Consistency
3 - Consistency
FaultSeverity
Any
Any
1 - Critical
2 - Significant
3 - Minor
Triggering market party
Any
Any
Any
Any
Any
Nonconformity file to
Same party
Same party
Both parties
Balance Supplier
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
Elhub Specification of Nonconformity Files
side 21
bilaterally with the GAP, so that the latter also changes its data in accordance with agreed data
values.
Name:
Short name:
Norwegian name:
Description:
Type:
Format:
Example:
3.3.3.8
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
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.
Name:
Short name:
Norwegian name:
Description:
Type:
Format:
Example:
3.3.3.9
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 EMF30000. See fault description
for how this is implemented.
EMF30009 (FaultLevel is 3 = Consistency with unique number
0009)
FaultDueToValue
This field contains the value from another market party which triggered the nonconformity
condition. The opposite market party must be retrieved from the relation on the metering point.
Name:
Short name:
Norwegian name:
Description:
Elhub Specification of Nonconformity Files
FaultDueToValue
FaultValue
Feil grunnet verdi
If appropriate and relevant, the actual value from another market
party triggering a nonconformity condition.
side 22
Type:
Format:
Example:
string(150)
Text(150)
61015812345
3.3.3.10 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.
Name:
Short
name:
Norwegian
name:
Description:
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, EMF300000
Type:
Format:
Example:
If FaultCode ends with 0, the field is considered NA.
string(150)
Text(150)
"Inconsisteny found when matching customer address with other
market party"
3.3.4 Metering value – Måleverdi
3.3.4.1
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.
Name:
Short name:
Norwegian name:
Description:
Elhub Specification of Nonconformity Files
SourcefileName
File
Filnavn kilde
Reference to the latest file containing the dataset having the
nonconformity.
side 23
Type:
Format:
Example:
3.3.4.2
MeteringPointUsed
Name:
Short name:
Norwegian name:
Description:
Type:
Format:
Example:
3.3.4.3
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)
707057500054119000
TimeSeriesType
Name:
Short name:
Norwegian name:
Description:
Type:
Values:
Example:
3.3.4.4
Text(80)
See filename specification
BS-999999999-0123456789012-20140919-MV_NCF_01.sdv
TimeSeriesType
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
E17
ProductType
Name:
Short name:
Norwegian name:
Description:
Type:
Values:
Example:
Elhub Specification of Nonconformity Files
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
8716867000030 = Energy Active
8716867000047 = Energy Reactive
8716867000030
side 24
3.3.4.5
ProcessingDateTime
Name:
Short name:
Norwegian name:
Description:
Type:
Format:
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-MM-DDTHH:MM:SSZ
where:
YYYY
MM
DD
HH
MM
SS
Example:
3.3.4.6
- 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.
2016-01-01T03:00:00Z
StartDate
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 (2014-1223T14:00:00Z - 2014-12-23T15:00:00Z) and (2014-12-23T15:00:00Z - 2014-12-23T16:00:00Z) are
continuous across 2014-12-23T15: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.
Name:
Short name:
Norwegian name:
Description:
Type:
Format:
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-MM-DDTHH:MM:SSZ
where:
YYYY
MM
DD
HH
MM
SS
Elhub Specification of Nonconformity Files
- 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.
side 25
Example:
3.3.4.7
2016-01-01T03:00:00Z
EndDate
Name:
Short name:
Norwegian name:
Description:
Type:
Format:
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-MM-DDTHH:MM:SSZ
where:
YYYY
MM
DD
HH
MM
SS
Example:
3.3.4.8
- 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.
2016-01-01T03:00:00Z
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.
Name:
Short name:
Norwegian name:
Description:
Type:
Format:
Example:
Elhub Specification of Nonconformity Files
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
side 26
3.3.4.9
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.
Name:
Short name:
Norwegian name:
Description:
Type:
Format:
Example:
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
3.3.4.10 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.
Name:
Short name:
Norwegian name:
Description:
Type:
Format:
Example:
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 EMF30000. See fault description
for how this is implemented.
EMF30009 (FaultLevel is 3 = Consistency with unique number
0009)
3.3.4.11 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.
Elhub Specification of Nonconformity Files
side 27
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.
Name:
Short
name:
Norwegian
name:
Description:
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, EMF300000
Type:
Format:
Example:
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 28