# Calculating and Verifying the UTRN Check Digit

 Page 226/258 Date 03.04.2021 Size 4.8 Mb.

## Calculating and Verifying the UTRN Check Digit

The UTRN Check Digit shall be calculated from the 19 decimal digit representation of the PTUT by a process equivalent to the following (Verhoeff’s) Algorithm37:

• setting an interim digit (referred to as IntDig) to have a value of zero;

• setting an index (referred to as K) to have a value of four;

• repeating the following steps with another index (referred to as J) taking the nineteen values of the integers from 1 to 19 in succession;

• setting CurDig to the value of the Jth digit of the 19 decimal digits of the PTUT, where the first digit is the most significant (leftmost as written) and the nineteenth digit the least significant;

• setting a third index (referred to as L) to the value in Table 14.8a using K as the Row Index and CurDig as the Column Index;

• if the value of K is less than 7, setting K to the value of K+1, otherwise setting K to zero;

1. setting IntDig to the value in Table 14.8b using IntDig as the Row Index and L as the Column Index;

• setting IntDig to the value in row 1 of Table 14.8c using the value of IntDig as the Column Index; and

• setting the UTRN Check Digit to the value of IntDig.

The UTRN Check Digit may be verified by undertaking exactly the same calculation on the 19 most significant digits of the UTRN, and comparing the result (the final value of IntDig, which would be used to set the UTRN Check Digit) to the 20th decimal digit which is the UTRN Check Digit.
 Column Index 0 1 2 3 4 5 6 7 8 9 Row 0 0 1 2 3 4 5 6 7 8 9 Index 1 1 5 7 6 2 8 3 0 9 4 2 5 8 0 3 7 9 6 1 4 2 3 8 9 1 6 0 4 3 5 2 7 4 9 4 5 3 1 2 6 8 7 0 5 4 2 8 6 5 7 3 9 0 1 6 2 7 9 3 8 0 6 4 1 5 7 7 0 4 6 9 1 3 2 5 8

Table 14.8a: Setting a third index

 Column Index 0 1 2 3 4 5 6 7 8 9 Row 0 0 1 2 3 4 5 6 7 8 9 Index 1 1 2 3 4 0 6 7 8 9 5 2 2 3 4 0 1 7 8 9 5 6 3 3 4 0 1 2 8 9 5 6 7 4 4 0 1 2 3 9 5 6 7 8 5 5 9 8 7 6 0 4 3 2 1 6 6 5 9 8 7 1 0 4 3 2 7 7 6 5 9 8 2 1 0 4 3 8 8 7 6 5 9 3 2 1 0 4 9 9 8 7 6 5 4 3 2 1 0

Table 14.8b: Setting IntDig using IntDig as a Row Index

 Column Index Row 0 1 2 3 4 5 6 7 8 9 Index 1 1 2 6 7 5 8 3 0 9 4

Table 14.8c: Setting IntDig using IntDig as a Column Index
1. ## Message Codes

Message Codes shall be 2 octets in length and shall take the values specified in the ‘Use Case reference’ tab in the Mapping Table.

For Messages specified by this GBCS, the most significant bit of the Message Code shall be 0b0.

1. ## Introduction – informative

This Section 16 sets out how Events and Alerts are handled. SMETS and CHTS define when Events occur and whether these Events are logged (in an Event Log) and additionally sent as an Alert via the HAN / WAN.

Table 16.2 defines Event Codes for events defined in SMETS and CHTS. It also indicates whether, as per SMETS and CHTS, there is a corresponding Alert issued over the Device’s network interface (containing the relevant Event Code). It is important to note that not all Event Codes have a corresponding Alert. Where Alert Code is used elsewhere in this document, it equates to Event Code in Table 16.2.

Alerts sent over the SMHAN are not subject to the same message categorisation as those sent over the WAN. An Alert sent over the SMHAN is a native ZSE message.

There are two Alert types. All have the same Grouping Header but different payloads as set out below:

• Alert type 1 - Payload comprises Alert Code and Timestamp only (two sub-types: DLMS and ZigBee). These are labelled ‘Y(1)’ in the ‘Alert WAN (Alert type)’ column in Table 16.2; and

• Alert type 2 - Payload comprises Alert Code, Timestamp and Use Case specific data as defined in Table 16.2 or main body of document (three sub-types: ASN.1, DLMS and ZigBee). These are labelled ‘Y(2)’ in the ‘Alert WAN (Alert type)’ column in Table 16.2.

Table 16.2 sets out the Alert type for each Alert Code. Examples of Use Case specific data include Billing Data Logs and content relating to future dated Commands (e.g. Message ID).

Table 16.2 sets out whether Alerts are mandated, mandatory conditional or non-mandated:

• Mandated - Alerts that Devices must support;

• Mandated conditional – Devices must support at least one from the specified group (e.g. there are seven Alerts in ‘mandated – conditional group 1’, Devices must support at least one of these seven); and

• Non-mandatory – no requirement for Devices to support, but where implemented Alert Codes shall have the meaning shown in Table 16.2. Further definition of these events may be found in the SSWG specifications38.

Alert construction is described in the GBCS in a number of places, including:

• Section 7.2.3 details common Message construction for all Alert types;

• Section 7.2.9 details Message construction for Alerts with DLMS COSEM Payloads. Table 7.2.9c details the required components of the Alert;

• Section 7.2.10 details Message construction for Alerts with ZSE Payloads. Table 7.2.10c details the required components of the Alert;

• Sections 11.2 and 13.3 detail the Message Construction for the Alerts with ASN.1 Payload; and

• Section 9.2.2 details the Message Construction for future dated Alerts.
1. ### Event Behaviour

Detail on Event behaviour can be found in SMETS and CHTS using the relevant SMETS and CHTS reference in Table 16.2.
1. ## Event and Alert Codes

Table 16.2 lists the valid Event and Alert Codes, and sets out their requirements.

Table 16.2: Event and Alert Codes

1. ## Event Logs

Only GSME, ESME, CHF and GPF have Event Logs. The requirement set out in Table 16.2 to log entries into Event Logs only applies to GSME, ESME, CHF and GPF as follows:

• Event Log (GSME, ESME, CHF and GPF);

• Security Event Log (GSME, ESME, CHF and GPF);

• Power Event Log (ESME); and

• ALCS Event Log (ESME).

Use Cases to read logs (all) and clear logs (event logs only) are detailed in the Mapping Table.