Version 1: Release Note 28 November 2014


Calculating and Verifying the UTRN Check Digit



Download 4.8 Mb.
Page226/258
Date03.04.2021
Size4.8 Mb.
1   ...   222   223   224   225   226   227   228   229   ...   258

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. Event / Alert Codes and related requirements

    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.

      1. Types of Alert


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.
      1. Alert Construction


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.

    1. Directory: government -> uploads -> system -> uploads -> attachment data -> file
      file -> Remove this if sending to pagerunnerr Page Title Light Rail Security Recommended Best Practice
      file -> 8 Section 1 : Sport
      file -> Notice of exercise of additional powers of seizure under Sections 50 or 51 of the Criminal Justice and Police Act 2001
      file -> Home office circular 004/2014 Powers to search for and seize invalid travel documents in Schedule 8 to the Anti-social Behaviour, Crime and Policing Act 2014
      file -> Consultation on the Royal Parks and Other Open Spaces (Amendment) (No. 2) Regulations 2012
      file -> Crown copyright 2012
      file -> This is the Report to Government by the Film Policy Review Panel The brief
      file -> Impact Assessment (IA)
      file -> Dcms/Wolfson Museums and Galleries Improvement Fund a public-Private Partnership (2002-2010)


      Share with your friends:
1   ...   222   223   224   225   226   227   228   229   ...   258




The database is protected by copyright ©essaydocs.org 2020
send message

    Main page