CHTS - Smart Energy Code

advertisement
Smart Metering Implementation
Programme
Communications Hub Technical
Specifications (CHTS)
Version 1.47: Release Note
18 November 2015
Release Note
This release note accompanies, but does not form part of CHTS v1.47. It describes the
revision history of CHTS.
Summary of main changes
This document is CHTS v1.47.
There are corrections of minor typographic errors throughout this document.
In addition, the sections of this document listed below incorporate specific changes and
updates to CHTS v1.46 that have been adopted through a number of Issue Resolution
Proposals (IRPs) and following the DECC Technical Specifications Issues Management
process.
Table of Section Changes
The sections of this document listed below incorporate changes and updates to CHTS v1.46
as follows:
Section
Changes
Section 4:
Changes at Sections 4.2.3, 4.5.1.9, 4.5.3 and 4.5.4.7 in summary as follows:
Glossary

Corrected previous wording - GSME credentials are in the CHF device log,
not the GPF device log

Aligning references to the latest versions of the Security Characteristics
documentation

Allowing for Payment-based debt payments in the Billing Data Log
Addition of definition for SECAS
Table of Revision History
Version
0.72
0.75
0.8
0.81
Date of Issue
02/08/12
08/08/12
17/08/12
29/08/12
Status
Draft
Draft
Draft
Draft
0.86
0.86d
0.86e
7/09/12
10/09/12
11/09/12
Draft
Draft
Draft
0.90
13/09/12
Draft
1.10
1.12
1.14
1.16
09/01/13
05/02/13
08/02/13
12/02/13
Draft
Draft
Draft
Draft
1.17
25/03/13
Draft
1.18
1.19
27/03/13
15/04/13
Draft
Draft
1.20
1.21
1.30
16/04/13
05/06/13
23/08/13
Draft
Draft
Draft
Change Summary
Draft for review
Updated following preliminary review
Updated following issue clarification
Updated following SSAG review comments and establishment of new
drafting principles
Internal Team Review for ISDS issue
Restructured as per SMETS
Added placeholders for content to cover monitoring, historic gas
calculations, buffering, network coordination and routing
Draft for issue with ISDS. Included comments from internal review,
added missing content, removed placeholders
Draft for review
Draft for review
Draft for review
Draft for issue with ISFT. Includes comments from internal review
and feedback from BEAMA
Includes comments from review with SDAG, CSP bidders and
BEAMA
Includes comments from internal review
Updates following regulatory review. Includes restructuring of the
document, and making more explicit the difference between the
Communications Hub functionality and the Gas Proxy.
For issue with Final ISFT.
Pre-Wragge review
Incorporating legal review comments, internal work on GBCS and
clarifications on security credentials.
1.31
1.32
1.4
06/09/13
13/09/13
23/12/13
Draft
Draft
Draft
1.41
30/04/14
Draft
1.42
28/05/14
Draft
1.43
25/06/14
Draft
1.44
03/07/14
Draft
1.45
10/07/14
Draft
1.45
1.46
29/07/14
28/11/14
Draft
Draft
1.47
18/11/2015
Draft
Incorporating further stakeholder comments
Baseline draft
Draft version incorporating changes made following internal review
and previously suggested revisions.
Draft version incorporating changes emerging following GBCS
review, previous TBDG review and CPA review.
Draft version incorporating comments on the changes proposed in
1.41.
Draft version for informal TBDG review incorporating changes
proposed in email to TBDG members on 10 June.
Draft version incorporating comments on the changes proposed in
1.43.
Draft version incorporating comments on the changes proposed in
1.43 and 1.44.
Draft version clarifying Random Number Generator requirements.
Draft version to align with GBCS v0.8.1. Changes include removal
of Data Restriction Flag, and specification of number of Devices to be
supported by GPF / CHF
Uplift incorporating changes and updates to CHTS v1.46 adopted
through the DECC Technical Specifications Issues Management
process
This page is intentionally left blank
Smart Metering Implementation
Programme
Communications Hub Technical
Specifications (CHTS)
Version 1.47
18 November 2015
DRAFT
CHTS
© Crown copyright 2015
You may re-use this information (not including logos) free of charge in any format or
medium, under the terms of the Open Government Licence.
To view this licence, visit www.nationalarchives.gov.uk/doc/open-government-licence/ or
write to the Information Policy Team, The National Archives, Kew, London TW9 4DU, or
email: psi@nationalarchives.gsi.gov.uk.
This document is also available from our website at www.gov.uk/decc.
Version: CHTS v1.47
Issued: 18 November 2015
Enquiries to:
Smart Metering Implementation Programme
Department of Energy & Climate Change
3 Whitehall Place, Area 1C
London, SW1A 2AW
Telephone: 0300 068 6659
Email: smartmetering@decc.gsi.gov.uk
Version 1.47
18 November 2015
Page 6
DRAFT
CHTS
Table of Contents
Note: Sections 1 and 2 of this document are not used.
3
Introduction ................................................................................................................ 8
4
Technical Specifications ........................................................................................... 9
4.1
Overview ................................................................................................................. 9
4.2 Testing and Certification Requirements ................................................................... 9
4.2.1
Conformance with the CHTS .......................................................................... 9
4.2.2
Conformance with the Great Britain Companion Specifications ...................... 9
4.2.3
Conformance with the Commercial Product Assurance Security Characteristic
for GB Smart Metering ................................................................................... 9
4.2.4
Interoperability with the Data and Communications Company Systems ......... 9
4.3
Physical Requirements ............................................................................................ 9
4.4 Functional Requirements....................................................................................... 11
4.4.1
Clock ............................................................................................................ 11
4.4.2
Communications .......................................................................................... 11
4.4.3
Data Storage ................................................................................................ 13
4.4.4
Buffering....................................................................................................... 14
4.4.5
Monitoring .................................................................................................... 14
4.4.6
Security ........................................................................................................ 14
4.4.7
Inter-PAN Connection .................................................................................. 17
4.5 Interface Requirements ......................................................................................... 17
4.5.1
CHF Interface Commands ............................................................................ 17
4.5.2
Receipt of Information by the GPF via the HAN Interface ............................. 19
4.5.3
Type 1 Device and Type 2 Device Information Provision from the GPF via the
HAN Interface............................................................................................... 19
4.5.4
GPF Interface Commands ............................................................................ 20
4.6 Data Requirements ............................................................................................... 21
4.6.1
Constant Data .............................................................................................. 21
4.6.2
Configuration Data ....................................................................................... 22
4.6.3
Operational Data .......................................................................................... 22
5
Glossary ................................................................................................................... 24
Version 1.47
18 November 2015
Page 7
DRAFT
CHTS
1
3 Introduction1
2
3
4
5
6
The requirement on the Data and Communications Company (DCC) to provide
Communications Hubs that comply with these Communications Hub Technical
Specifications (CHTS) arises from Part E of the Smart Meter Communication Licence
(granted pursuant to sections 7AB(2) and (4) of the Gas Act 1986 and sections 6(1A) and
(1C) of the Electricity Act 1989).
7
8
9
Section 4 of this document describes the minimum physical, functional, interface, data,
testing and certification requirements of a Communications Hub that the DCC is required to
provide to comply with these Licence and SEC requirements.
10
11
12
13
14
15
16
17
This document has been brought into force by the Secretary of State on [ ] for the
purposes of the relevant licence conditions. CHTS v1.45 was notified to the European
Commission in accordance with the requirements of Article 8 of Directive 98/34/EC of the
European Parliament and of the Council laying down a procedure for the provision of
information in the field of technical standards and regulations (OJ L 204, 21.7.1998, p. 37) as
amended by Directive 98/48/EC of the European Parliament and of the Council (OJ L 217,
5.8.1998, p. 18). The Government is currently considering if re-notification is required due to
the changes made in this version (v1.47), compared to v1.45.
18
19
20
The Smart Metering technical and security architecture is based on a suite of agreed, open
standards, reflecting the UK Government strategy to facilitate the development of third party
innovative solutions for consumer devices.
21
22
23
Mutual recognition: Any requirement for a Communications Hub to comply with the CHTS
or any of the technical specifications contained or referred to in this document shall be
satisfied by compliance with:
24
25

a relevant standard or code of practice of a national standards body or equivalent body
of any EEA State or Turkey; or
26

any relevant international standard recognised for use in any EEA State or Turkey; or
27
28

any relevant technical regulation with mandatory or de facto mandatory application for
marketing or use in any EEA State or Turkey,
29
30
31
32
in so far as compliance with the standard, code of practice or technical regulation in question
enables the equipment to achieve, in an equivalent manner, all of the physical, functional,
interface and data capabilities that are achieved by compliance with the requirements of
CHTS or any of the technical specifications contained or referred to in this document.
1
Sections 1 and 2 of this document are not used
Version 1.47
18 November 2015
Page 8
DRAFT
CHTS
33
4 Technical Specifications
34
4.1 Overview
35
36
37
38
Section 4 of this document describes the minimum physical, minimum functional, minimum
interface, minimum data and minimum testing and certification requirements of a
Communications Hub (CH) that the DCC is required to provide to comply with Part E of the
Smart Meter Communication Licence and section [F] of the Smart Energy Code (SEC).
39
This Section 4 includes requirements for:
40
41
i.
ii.
Communications Hub Function (CHF) of a CH; and
Gas Proxy Function (GPF) of a CH.
42
43
44
Where in this Section 4 a requirement is expressed to be a requirement of the CHF or the
GPF it shall be construed as a requirement of the CH to be delivered through the CHF or the
GPF as the case may be.
45
4.2 Testing and Certification Requirements
46
4.2.1 Conformance with the CHTS
47
48
A CH shall have been tested to ensure that it meets the requirements described in this
Section 4, and evidence must be available to confirm such testing and conformance.
49
50
4.2.2 Conformance with the Great Britain Companion
Specifications2
51
52
A CH shall meet the requirements described in the current version of the Great Britain
Companion Specifications meaning v0.8.2 or later as published on the SECAS website.
53
54
55
A CH shall have been certified by the ZigBee Alliance as compliant with the ZigBee SEP
v1.2 requirements described in the current version of the Great Britain Companion
Specifications meaning v0.8.2 or later as published on the SECAS website.
56
57
4.2.3 Conformance with the Commercial Product Assurance
Security Characteristic for GB Smart Metering3
58
59
60
A CH shall meet the requirements described in the current version of the Commercial
Product Assurance Security Characteristic Smart Metering - Communications Hub meaning
v1.2 or later as published on CESG’s Website.
61
62
63
A CH shall be certified by CESG as compliant with the current version of the Commercial
Product Assurance Security Characteristic Smart Metering - Communications Hub meaning
v1.2 or later as published on CESG’s Website.
64
65
4.2.4 Interoperability with the Data and Communications Company
Systems
66
67
68
A CH shall be interoperable with DCC systems such that the DCC need not make any
adjustments to its systems in order to establish Communications Links (as described in this
Section 4) with the CH via its WAN Interface.
69
4.3 Physical Requirements
70
A CH shall as a minimum include the following components:
2
The current version of Great Britain Companion Specification can be found here:
https://www.smartenergycodecompany.co.uk/sec/the-developing-sec
3
The current version of CPA Security Characteristics can be found here: https://www.cesg.gov.uk/servicecatalogue/ProductAssurance/CPA/Pages/Security-Characteristics.aspx
Version 1.47
18 November 2015
Page 9
DRAFT
71
72
73
74
75
76
i.
ii.
iii.
iv.
v.
vi.
CHTS
a Clock;
a Data Store;
a HAN Interface;
a Random Number Generator;
a WAN Interface; and
an Intimate Physical Interface.
77
78
79
A CH shall operate using DC power and be capable of performing the minimum functional,
interface and data requirements described in Sections 4.4, 4.5 and 4.6 respectively without
consuming more than an average of 1 watt of electricity under normal operating conditions.
80
81
A CH shall be capable of automatically resuming operation after a power failure in its
operating state prior to such failure.
82
The CH shall:
83
84
85
86
87
88
89
90
91
92
93
vii.
viii.
ix.
permanently display the CHF Identifier(4.6.1.1) on the CH;
permanently display the GPF Identifier(4.6.1.4) on the CH; and
have a Secure Perimeter.
The HAN Interface of the CH shall be capable of establishing a ZigBee SEP v1.2 Smart
Metering Home Area Network which:
x.
xi.
xii.
xiii.
operates within the 2400 – 2483.5 MHz harmonised frequency band;
supports the routing (as set out in Section 4.4.2.1) of Commands, Responses, and
Alerts to and from Devices;
supports the Communications Links described in Section 4.5.2 and 4.5.3; and
supports Certificate-based Key Establishment Cryptographic Suite 2 as described in
ZigBee SEP v1.2.
94
95
On first establishing a ZigBee SEP v1.2 Smart Metering Home Area Network the CH shall be
capable of fixing the frequency at which its HAN Interface operates.
96
97
98
The CH shall be designed taking all reasonable steps so as to prevent Unauthorised
Physical Access and Unauthorised communications through its Secure Perimeter that could
compromise the Confidentiality and / or Data Integrity of:
99
100
101
102
103
104
xiv.
xv.
xvi.
xvii.
xviii.
xix.
105
stored or executing on the CH.
106
107
108
The CH shall be capable of detecting any attempt at Unauthorised Physical Access through
its Secure Perimeter that could compromise such Confidentiality and / or Data Integrity and
on such detection shall be capable of:
109
110
xx.
Personal Data;
Consumption data used for billing;
Security Credentials;
Random Number Generator;
Cryptographic Algorithms; and
Firmware and data essential for ensuring its Integrity,
providing evidence of such an attempt through the use of tamper evident coatings or
seals;
111
and where reasonably practicable:
112
113
xxi.
xxii.
114
115
116
The CH shall be designed taking all reasonable steps to ensure that its HAN Interface and
WAN Interface do not cause detriment to Communications Links formed with Devices
connected to its Intimate Physical Interface.
generating an entry to that effect in the CHF Security Log(4.6.3.5); and
generating and sending an Alert to that effect via its WAN Interface.
Version 1.47
18 November 2015
Page 10
DRAFT
CHTS
117
4.4 Functional Requirements
118
This section describes the minimum functions that a CH shall be capable of performing.
119
4.4.1 Clock
120
121
122
The Clock forming part of the CH shall be capable of operating so as to be accurate to within
10 seconds of the UTC date and time under normal operating conditions. The CH shall be
capable of maintaining the CHF Date and Time(4.6.3.1) and:
123
124
125
126
127
i.
ii.
marking this to indicate if its Communications Link via the WAN Interface is not
available; and
making the CHF Date and Time(4.6.3.1) available to Devices with which the CHF
has established a Communications Link (as set out in Section 4.4.2.1) via its HAN
interface.
128
4.4.2 Communications
129
4.4.2.1
130
131
132
The CHF shall be capable of establishing and maintaining Communications Links via the
HAN interface with a minimum of four ESME, one GSME, one GPF, seven Type 1 Devices
(including a minimum of two PPMIDs) and three Type 2 Devices.
133
134
135
The CHF shall be capable of establishing a Communications Link via the HAN Interface with
a Device for a minimum of one hour following receipt of that Device’s Security Credentials
(as set out in Section 4.5.1.2).
136
137
138
139
The CHF shall only be capable of establishing a Communications Link via the HAN Interface
with a Device with Security Credentials in the CHF Device Log(4.6.2.1) and shall not be
capable of establishing a Communications Link via the HAN Interface with any other
Devices.
140
141
142
On establishing such a Communications Link with a Device, the CHF shall be capable of
recording the UTC date and time of such establishment in the relevant part of the CHF
Communications Store(4.6.3.2).
143
144
145
146
The CHF shall only be capable of establishing and maintaining a Communications Link via
the WAN Interface with the Wide Area Network Provider for the Premises in which the CH is
installed and shall not be capable of establishing a Communications Link via the WAN
Interface with any other person.
147
148
149
The CHF shall be capable of ensuring that the security characteristics of all Communications
Links it establishes meet the requirements described in CHF Secure
Communications(4.4.6.6).
150
151
When any Command addressed to the CHF is received by the CHF via any Communications
Link, and again when the Command is due to be executed, the CHF shall be capable of:
152
153
154
155
156
i.
ii.
iii.
Communications Links with the CHF
using the Security Credentials the CHF holds, Authenticating to a Trusted Source
the Command;
verifying in accordance with CHF Role-based Access Control(4.4.6.2.3) that the
sender of the Command is Authorised to execute the Command; and
verifying the integrity of the Command.
157
158
159
160
On failure of any of (i) to (iii) above, the CHF shall be capable of generating an entry in the
CHF Security Log(4.6.3.5) to that effect, discarding the Command without execution and
without either generating or sending a Response, and generating and sending an Alert to
that effect via the WAN Interface.
161
162
Where the Command is not due to be executed immediately, the CHF shall be capable of
generating and sending a Response via the WAN Interface to confirm successful receipt.
Version 1.47
18 November 2015
Page 11
DRAFT
CHTS
163
164
165
166
When executing a Command, the CHF shall be capable of generating and sending a
Response via both the WAN Interface and the HAN Interface, which shall either confirm
successful execution of the Command or shall detail why it has failed to execute the
Command.
167
168
The CHF shall only be capable of addressing a Response to the sender of the relevant
Command.
169
The CHF shall be capable of routing Commands, Responses, and Alerts:
170
171
172
173
174
iv.
v.
vi.
from each Device in the CHF Device Log(4.6.2.1) to the Devices in the CHF Device
Log(4.6.2.1) that is the intended recipient;
from each Device in the CHF Device Log(4.6.2.1) to the WAN Interface; and
from the WAN Interface to the Device in the CHF Device Log(4.6.2.1) that is the
intended recipient.
175
176
The CHF shall be capable of storing the Security Credentials of a minimum of 16 Devices in
the CHF Device Log(4.6.2.1).
177
4.4.2.2
178
179
180
A GPF shall be capable of ensuring that the security characteristics of all Communications
Links it establishes meet the requirements described in GPF Secure
Communications(4.4.6.7).
181
182
When any Command addressed to the GPF is received by the GPF via any Communications
Link, and again when the Command is due to be executed, a GPF shall be capable of:
183
184
185
186
187
i.
ii.
iii.
Communications Links with the GPF
using the Security Credentials the GPF holds, Authenticating to a Trusted Source
the Command;
verifying in accordance with GPF Role-based Access Control(4.4.6.2.6) that the
sender of the Command is Authorised to execute the Command; and
verifying the integrity of the Command.
188
189
190
191
On failure of any of (i) to (iii) above, the GPF shall be capable of generating an entry in the
GPF Security Log(4.6.3.11) to that effect, discarding the Command without execution and
without either generating or sending a Response, and generating and sending an Alert to
that effect via the WAN Interface.
192
193
Where the Command is not due to be executed immediately, the GPF shall be capable of
generating and sending a Response via the WAN Interface to confirm successful receipt.
194
195
196
When executing the Command the GPF shall be capable of generating and sending a
Response via the WAN Interface, which shall either confirm successful execution of the
Command or shall detail why it has failed to execute the Command.
197
198
The GPF shall only be capable of addressing a Response to the sender of the relevant
Command.
199
4.4.2.2.1 Communications Links with GSME over the HAN Interface
200
201
The GPF shall be capable of establishing and maintaining Communications Links via the
HAN Interface with GSME.
202
203
The GPF shall be capable of receiving the information defined in Section 4.6.3.9 from
GSME.
204
4.4.2.2.2 Communications Links with Type 1 Devices over the HAN Interface
205
206
The GPF shall be capable of establishing and maintaining Communications Links via the
HAN Interface with a minimum of one Type 1 Device.
Version 1.47
18 November 2015
Page 12
DRAFT
CHTS
207
208
209
The GPF shall only be capable of establishing a Communications Link with a Type 1 Device
with Security Credentials in the GPF Device Log(4.6.2.3) and shall not be capable of
establishing a Communications Link via the HAN Interface with any other Devices.
210
The GPF shall be capable of supporting the following types of Communications Links:
211
212
213
214
215
i.
ii.
iii.
iv.
receiving the Commands (set out in Section 4.5.4) from a Type 1 Device;
generating and sending the Responses (set out in Section 4.5.4) to a Type 1 Device;
generating and sending the information (set out in Section 4.6) to a Type 1 Device;
and
sending Alerts to a Type 1 Device, including those it has received from GSME.
216
4.4.2.2.3 Communications Links with Type 2 Devices over the HAN Interface
217
218
The GPF shall be capable of establishing and maintaining Communications Links via the
HAN Interface with a minimum of four Type 2 Devices.
219
220
221
The GPF shall only be capable of establishing a Communications Link with a Type 2 Device
with Security Credentials in the GPF Device Log(4.6.2.3) and shall not be capable of
establishing a Communications Link via the HAN Interface with any other Devices.
222
The GPF shall be capable of supporting the following types of Communications Links:
223
224
i.
ii.
generating and sending information (set out in Section 4.6) to a Type 2 Device; and
sending Alerts to a Type 2 Device, including those it has received from the GSME.
225
4.4.3 Data Storage
226
227
A CH shall be capable of retaining all information held in its Data Store at all times, including
on loss of power.
228
4.4.3.1
229
4.4.3.1.1 Gas Consumption and Energy Consumption data
230
231
232
The GPF shall be capable of using the GSME Cumulative and Historical Value Store and the
GSME Cumulative Current Day Value Store (received from GSME as set out in Section
4.5.2) to calculate and store to:
233
i.
234
235
236
237
238
239
240
241
GSME data
the GPF Cumulative and Historical Value Store [INFO](4.6.3.6):
a)
b)
c)
d)
e)
f)
ii.
Energy Consumption on the Day up to the Local Time;
Energy Consumption on each of the eight Days prior to such Day;
Energy Consumption in the Week in which the calculation is performed;
Energy Consumption in each of the five Weeks prior to such Week;
Energy Consumption in the month in which the calculation is performed;
Energy Consumption in the thirteen months prior to such month; and
the GPF Daily Gas Consumption Log [INFO](4.6.3.7), the Gas Consumption on each
of the 731 Days prior to the current Day.
242
4.4.3.1.2 Cost of Gas Consumption data
243
244
245
246
The GPF shall be capable of using the GSME Cumulative and Historical Value Store and the
GSME Cumulative Current Day Value Store (received from GSME as set out in Section
4.5.2) to calculate and store to the GPF Cumulative and Historical Value Store
[INFO](4.6.3.6) the cost of:
247
248
249
250
251
252
i.
ii.
iii.
iv.
v.
vi.
Energy Consumption on the Day up to the Local Time;
Energy Consumption on each of the eight Days prior to such Day;
Energy Consumption in the Week in which the calculation is performed;
Energy Consumption in each of the five Weeks prior to such Week;
Energy Consumption in the month in which the calculation is performed; and
Energy Consumption in the thirteen months prior to such month.
Version 1.47
18 November 2015
Page 13
DRAFT
CHTS
253
4.4.3.1.3 Half hour profile data
254
255
256
257
258
259
The GPF shall be capable of using the GSME Profile Data Log, the GSME Cumulative
Current Day Value Store, the GSME Conversion Factor and the GSME Calorific Value
(received from GSME as set out in Section 4.5.2) to calculate and store to the GPF Profile
Data Log [INFO](4.6.3.10) Gas Consumption in each 30 minute period (commencing at the
start of minutes 00 and 30 in each hour) and the UTC date and time at the end of the 30
minute period to which the Gas Consumption relates.
260
4.4.4 Buffering
261
262
A CHF shall be capable of Buffering all Commands intended for GSME with Security
Credentials recorded in the CHF Device Log(4.6.2.1).
263
264
A CHF shall be capable of prioritising the forwarding of any GSME Add Credit Commands
and GSME Activate Emergency Credit Commands.
265
A CHF shall be capable of Buffering a Command to receive Firmware intended for ESME.
266
267
A CHF shall be capable of Buffering Commands, Responses and Alerts to be sent via the
WAN interface.
268
Under normal operating conditions, a CHF shall be capable of Buffering at all times:
269
270
271
272
i.
ii.
iii.
iv.
CHF Device Log(4.6.2.1) Alerts;
Device Commissioning Alerts;
Responses to Critical Commands; and
other Critical Alerts.
273
4.4.5 Monitoring
274
275
276
A CH shall be capable of recording the UTC date and time at which the power supply to the
CH is interrupted and the UTC date and time at which the power supply to the CH is restored
and generating entries to that effect in the CHF Event Log(4.6.3.3).
277
4.4.6 Security
278
4.4.6.1
279
280
281
282
A CH shall be designed taking all reasonable steps so as to ensure that any failure or
compromise of its integrity shall not compromise the Security Credentials or Personal Data
stored on it or compromise the integrity of any other Device to which it is connected by
means of a Communications Link.
283
284
285
The CH shall be capable of verifying its Firmware at power-on and prior to activation of the
Firmware, to verify that the Firmware, at that time, is in the form originally received. On
failure of verification the CH shall be capable of:
286
287
i.
ii.
General
generating an entry to that effect in the CHF Security Log(4.6.3.5); and
generating and sending an Alert to that effect via the WAN Interface.
288
289
A CHF shall be capable of logging in the CHF Security Log(4.6.3.5) the occurrence and type
of any Sensitive Event.
290
291
A GPF shall be capable of logging in the GPF Security Log(4.6.3.11) the occurrence and
type of any Sensitive Event.
292
293
A CHF shall be capable of securely disabling Critical Commands other than those
Commands set out in Section 4.5.1 that are Critical Commands.
294
295
A GPF shall be capable of securely disabling Critical Commands other than those
Commands set out in Section 4.5.4 that are Critical Commands.
Version 1.47
18 November 2015
Page 14
DRAFT
CHTS
296
4.4.6.2
297
4.4.6.2.1 CHF Private Keys
298
299
A CHF shall be capable of generating Public-Private Key Pairs to support the Cryptographic
Algorithms set out in Section 4.4.6.3.
300
301
302
The CHF shall be capable of securely storing such Private Keys and shall be capable of
formatting and sending via each of the HAN Interface and the WAN Interface a Certificate
Signing Request containing the corresponding Public Key and the CHF Identifier(4.6.1.1).
303
The CHF shall be capable of securely storing Key Agreement values.
304
4.4.6.2.2 CHF Public Key Certificates
305
306
A CHF shall be capable of securely storing Security Credentials from Certificates including
for use in the Cryptographic Algorithms as set out in Section 4.4.6.3.
307
308
309
During the replacement of any CHF Security Credentials(4.6.2.2) (as set out in Section
4.5.1.10), the CHF shall be capable of ensuring that the CHF Security Credentials(4.6.2.2)
being replaced remain usable until the successful completion of the replacement.
310
4.4.6.2.3 CHF Role-based Access Control
311
312
The CHF shall be capable of restricting Authorisation to execute Commands and of issuing
Alerts according to Role permissions.
313
4.4.6.2.4 GPF Private Keys
314
315
A GPF shall be capable of generating Public-Private Key Pairs to support the Cryptographic
Algorithms set out in Section 4.4.6.4.
316
317
318
The GPF shall be capable of securely storing such Private Keys and shall be capable of
formatting and sending via the WAN Interface a Certificate Signing Request containing the
corresponding Public Key and the GPF Identifier(4.6.1.4).
319
The GPF shall be capable of securely storing Key Agreement values.
320
4.4.6.2.5 GPF Public Key Certificates
321
322
A GPF shall be capable of securely storing Security Credentials from Certificates including
for use in the Cryptographic Algorithms as set out in Section 4.4.6.4.
323
324
325
During the replacement of any GPF Security Credentials(4.6.2.4) (as set out in Section
4.5.4.8) the GPF shall be capable of ensuring that the GPF Security Credentials(4.6.2.4)
being replaced remain usable until the successful completion of the replacement.
326
4.4.6.2.6 GPF Role-based Access Control
327
328
The GPF shall be capable of restricting Authorisation to execute Commands and of issuing
Alerts according to Role permissions.
329
4.4.6.3
330
The CHF shall be capable of supporting the following Cryptographic Algorithms:
331
332
333
334
335
336
337
338
339
i.
ii.
iii.
Security Credentials
CHF Cryptographic Algorithms
Elliptic Curve DSA;
Elliptic Curve DH; and
SHA-256.
In executing and creating any Command, Response or Alert, the CHF shall be capable of
applying Cryptographic Algorithms (alone or in combination) for:
iv.
v.
vi.
vii.
Digital Signing;
Digital Signature verification;
Hashing;
Message Authentication; and
Version 1.47
18 November 2015
Page 15
DRAFT
340
viii.
CHTS
Encryption and Decryption.
341
4.4.6.4
342
The GPF shall be capable of supporting the following Cryptographic Algorithms:
343
344
345
346
347
348
349
350
351
352
i.
ii.
iii.
GPF Cryptographic Algorithms
Elliptic Curve DSA;
Elliptic Curve DH; and
SHA-256.
In executing and creating any Command, Response or Alert, the GPF shall be capable of
applying Cryptographic Algorithms (alone or in combination) for:
iv.
v.
vi.
vii.
viii.
Digital Signing;
Digital Signature verification;
Hashing;
Message Authentication; and
Encryption and Decryption.
353
4.4.6.5
354
355
The CH shall only be capable of activating its Firmware on receipt of an Activate CH
Firmware Command (as set out in Section 4.5.1.1).
356
4.4.6.6
357
358
The CHF shall be capable of preventing and detecting, on all of its interfaces, Unauthorised
access that could compromise the Confidentiality and / or Data Integrity of:
359
360
361
362
363
364
365
366
367
368
369
370
371
i.
ii.
iii.
iv.
CH Firmware
CHF Secure Communications
Personal Data whilst being transferred via an interface;
Consumption data used for billing whilst being transferred via an interface;
Security Credentials whilst being transferred via an interface; and
Firmware and data essential for ensuring its Integrity whilst being transferred via an
interface,
and any Command that could compromise the Confidentiality and / or Data Integrity of:
v.
vi.
vii.
viii.
Personal Data;
Consumption data used for billing;
Security Credentials; and
Firmware and data essential for ensuring its Integrity,
stored or executing on the CHF, and on such detection shall be capable of:
ix.
x.
generating an entry to that effect in the CHF Security Log(4.6.3.5); and
generating and sending an Alert to that effect via the WAN Interface.
372
373
The CHF shall be capable of employing techniques to protect against Replay Attacks
relating to Commands received.
374
375
The CHF shall not be capable of executing a Command to modify or delete entries from the
CHF Security Log(4.6.3.5) or the GPF Security Log(4.6.3.11).
376
4.4.6.7
377
378
The GPF shall be capable of preventing and detecting, on all of its interfaces, Unauthorised
access that could compromise the Confidentiality and / or Data Integrity of:
379
380
381
382
383
384
i.
ii.
iii.
iv.
GPF Secure Communications
Personal Data whilst being transferred via an interface;
Gas Consumption data used for billing whilst being transferred via an interface;
Security Credentials whilst being transferred via an interface; and
Firmware and data essential for ensuring its Integrity whilst being transferred via an
interface,
and any Command that could compromise the Confidentiality and / or Data Integrity of:
Version 1.47
18 November 2015
Page 16
DRAFT
385
386
387
388
389
390
391
v.
vi.
vii.
viii.
CHTS
Personal Data;
Gas Consumption data used for billing;
Security Credentials; and
Firmware and data essential for ensuring its Integrity,
stored or executing on the GPF, and on such detection shall be capable of:
ix.
x.
generating an entry to that effect in the GPF Security Log(4.6.3.11); and
generating and sending an Alert to that effect via the WAN Interface.
392
393
The GPF shall be capable of employing techniques to protect against Replay Attacks
relating to Commands received.
394
395
The GPF shall not be capable of executing a Command to modify or delete entries from the
GPF Security Log(4.6.3.11).
396
4.4.7 Inter-PAN Connection
397
398
399
The CH shall be capable of permitting devices to establish an Inter-PAN Connection for a
period of one hour at CH power-on. Where such a connection has been established, the CH
shall be capable of sending:
400
401
i.
ii.
Responses and Alerts it has generated; and
Responses and Alerts it has received from other Devices,
402
to the Inter-PAN connected device.
403
4.5 Interface Requirements
404
405
This section describes the minimum required interactions that a CH shall be capable of
undertaking via the HAN Interface and the WAN Interface.
406
4.5.1 CHF Interface Commands
407
408
409
The CHF shall be capable of executing the Commands set out in this Section 4.5.1. The
CHF shall be capable of logging all Commands received and Outcomes in the CHF Event
Log(4.6.3.3).
410
411
412
413
The CHF shall be capable of executing Commands immediately on receipt (‘immediate
Commands’) and where specified in the Great Britain Companion Specification at a future
date (‘future dated Commands’). A future dated Command shall include the UTC date and
time at which the Command shall be executed by the CHF.
414
415
416
417
418
The CHF shall be capable of cancelling a future dated Command. A future dated Command
shall be capable of being cancelled by an Authorised party, subject to CHF Role-based
Access Control (as set out in Section 4.4.6.2.3). The CHF shall be capable of generating
and sending a Response acknowledging that a future dated Command has been
successfully cancelled.
419
4.5.1.1
420
A Command to activate Firmware.
421
422
In executing the Command the CH shall be capable of installing new CH Firmware using a
mechanism that is robust against failure and loss of data.
423
424
425
The new Firmware shall include version information. Where new Firmware is successfully
installed, the CH shall be capable of recording the version information of that new Firmware
in CH Firmware Version(4.6.3.4).
426
4.5.1.2
427
428
A Command to add Security Credentials for a Type 1 Device, Type 2 Device, ESME, GSME
or a GPF to the CHF Device Log(4.6.2.1).
Activate CH Firmware
Add CHF Device Security Credentials
Version 1.47
18 November 2015
Page 17
DRAFT
429
CHTS
In executing the Command, the CHF shall be capable of:
430
431
432
433
i.
ii.
verifying the Security Credentials;
generating and sending an Alert to this effect, including details of the revised CHF
Device Log(4.6.2.1), via the WAN Interface; and
recording the Command and Outcome to the CHF Security Log(4.6.3.5).
iii.
434
4.5.1.3
435
A Command to clear all entries from the CHF Event Log(4.6.3.3).
436
437
The CHF shall be capable of logging that the Command has been executed in the CHF
Security Log(4.6.3.5).
438
4.5.1.4
439
440
A Command to generate a Public–Private Key Pair and issue a corresponding Certificate
Signing Request.
441
4.5.1.5
442
443
A Command to read the value of one or more of the CHF configuration data items set out in
Section 4.6.2.
444
445
In executing the Command, the CHF shall be capable of sending such value(s) in a
Response.
446
4.5.1.6
447
448
A Command to read the value of one or more of the constant data items set out in Section
4.6.1.
449
450
In executing the Command, the CHF shall be capable of sending such value(s) in a
Response.
451
4.5.1.7
452
453
A Command to read the value of one or more of the operational data items set out in Section
4.6.3.
454
455
In executing the Command, the CHF shall be capable of sending such value(s) in a
Response.
456
4.5.1.8
457
A Command to receive CH Firmware.
458
In executing the Command the CH shall be capable of:
Clear CHF Event Log
Issue CHF Security Credentials
Read CHF Configuration Data
Read CHF Constant Data
Read CHF Operational Data
Receive CH Firmware
459
460
i.
ii.
461
4.5.1.9
462
A Command to remove Security Credentials for a Device from the CHF Device Log(4.6.2.1).
463
In executing the Command the CHF shall be capable of:
464
465
466
467
468
469
470
i.
ii.
only accepting new Firmware from an Authorised and Authenticated source; and
verifying the Authenticity and integrity of new Firmware before installation.
Remove CHF Device Security Credentials
generating and sending an Alert to this effect, including details of the revised CHF
Device Log(4.6.2.1), via the WAN interface; and
recording the Command and Outcome to the CHF Security Log(4.6.3.5).
Where the Device removed is a GSME, the GPF shall be capable of permanently deleting all
the data stored in the GPF Cumulative and Historical Value Store [INFO](4.6.3.6), GPF Daily
Gas Consumption Log [INFO](4.6.3.7), GPF Profile Data Log [INFO](4.6.3.10) and GPF
GSME Proxy Log(4.6.3.9).
Version 1.47
18 November 2015
Page 18
DRAFT
CHTS
471
4.5.1.10 Replace CHF Security Credentials
472
A Command to replace CHF Security Credentials(4.6.2.2) held within the CHF.
473
In executing the Command the CHF shall be capable of:
474
475
i.
ii.
maintaining the Command’s Transactional Atomicity; and
recording the Command and Outcome to the CHF Security Log(4.6.3.5).
476
4.5.1.11 Restore CHF Device Log
477
A Command to restore the details in the CHF Device Log(4.6.2.1).
478
479
In executing the Command, the CHF shall be capable of recording the Command and
Outcome to the CHF Security Log(4.6.3.5).
480
4.5.2 Receipt of Information by the GPF via the HAN Interface
481
482
483
484
A GPF shall be capable, immediately upon establishment of a Communications Link with
GSME of receiving GSME Constant Data, GSME Configuration Data, GSME Operational
Data and (with the exception of the GSME Cumulative and Historical Value Store and the
GSME Profile Data Log) receiving updates of any changes in that data.
485
486
487
488
489
Where changes have been made to the GSME Billing Data Log in accordance with the
timetable set out in the GSME Billing Calendar, the GPF shall be capable of generating and
sending an Alert containing the most recent entries of the GSME Tariff TOU Register Matrix,
the GSME Tariff Block Counter Matrix and the GSME Consumption Register in the GSME
Billing Data Log.
490
491
4.5.3 Type 1 Device and Type 2 Device Information Provision from
the GPF via the HAN Interface
492
493
494
495
496
The GPF shall be capable, immediately upon establishment of a Communications Link with
a Type 1 Device (as set out in Section 4.4.2.2.2) and a Type 2 Device (as set out in Section
4.4.2.2.3), of providing the data annotated [INFO] set out in Section 4.6 and in addition the
following data from the GPF GSME Proxy Log(4.6.3.9) to the Type 1 Device or the Type 2
Device as applicable (with timely updates of any changes to all such data):
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
i.
ii.
iii.
iv.
v.
vi.
vii.
viii.
ix.
x.
xi.
xii.
xiii.
xiv.
xv.
xvi.
xvii.
xviii.
xix.
xx.
xxi.
xxii.
Accumulated Debt Register;
Active Tariff Price;
Calorific Value;
Consumption Register;
Contact Details;
Conversion Factor;
Currency Units;
Customer Identification Number;
Debt Recovery per Payment;
Debt Recovery Rates [1 … 2];
Debt Recovery Rate Cap;
Disablement Threshold;
Emergency Credit Balance;
Emergency Credit Limit;
Emergency Credit Threshold;
Low Credit Threshold;
Meter Balance;
Meter Point Reference Number (MPRN);
Non-Disablement Calendar;
Payment Debt Register;
Payment Mode;
Profile Data Log;
Version 1.47
18 November 2015
Page 19
DRAFT
519
520
521
522
523
524
525
526
527
528
529
xxiii.
xxiv.
xxv.
xxvi.
xxvii.
xxviii.
xxix.
xxx.
xxxi.
xxxii.
xxxiii.
CHTS
Standing Charge;
Supplier Message;
Supply State;
Tariff Block Counter Matrix;
Tariff Block Price Matrix;
Tariff Switching Table;
Tariff Threshold Matrix;
Tariff TOU Price Matrix;
Tariff TOU Register Matrix;
Time Debt Registers [1 … 2]; and
Payment-based debt payments in the Billing Data Log.
530
4.5.4 GPF Interface Commands
531
532
533
The GPF shall be capable of executing the Commands set out in this Section 4.5.4. The
GPF shall be capable of logging all Commands received and Outcomes in the GPF Event
Log(4.6.3.8).
534
535
536
537
The GPF shall be capable of executing Commands immediately on receipt (‘immediate
Commands’) and where specified in the Great Britain Companion Specification at a future
date (‘future dated Commands’). A future dated Command shall include the UTC date and
time at which the Command shall be executed by the GPF.
538
539
540
541
542
The GPF shall be capable of cancelling a future dated Command. A future dated Command
shall be capable of being cancelled by an Authorised party, subject to GPF Role-based
Access Control (as set out in Section 4.4.6.2.6). The GPF shall be capable of generating
and sending a Response acknowledging that a future-dated Command has been
successfully cancelled.
543
4.5.4.1
544
545
A Command to add Security Credentials for a Type 1 Device, Type 2 Device or GSME to the
GPF Device Log(4.6.2.3).
546
In executing the Command, the GPF shall be capable of:
i.
ii.
Add GPF Device Security Credentials
547
548
549
550
verifying the Security Credentials;
generating and sending an Alert to this effect, including details of the revised GPF
Device Log(4.6.2.3), via the WAN Interface; and
recording the Command and Outcome to the GPF Security Log(4.6.3.11).
iii.
551
4.5.4.2
552
A Command to clear all entries from the GPF Event Log(4.6.3.8).
553
554
The GPF shall be capable of logging that the Command has been executed in the GPF
Security Log(4.6.3.11).
555
4.5.4.3
556
557
A Command to generate a Public-Private Key Pair and issue a corresponding Certificate
Signing Request.
558
4.5.4.4
559
560
A Command to read the value of one or more of the GPF configuration data items set out in
Section 4.6.2.
561
562
In executing the Command, the GPF shall be capable of sending such value(s) in a
Response.
Clear GPF Event Log
Issue GPF Security Credentials
Read GPF Configuration Data
Version 1.47
18 November 2015
Page 20
DRAFT
CHTS
563
4.5.4.5
564
565
A Command to read the value of one or more of the GPF constant data items set out in
Section 4.6.1.
566
567
In executing the Command, the GPF shall be capable of sending such value(s) in a
Response.
568
4.5.4.6
569
570
A Command to read the value of one or more of the GPF operational data items set out in
Section 4.6.3.
571
572
In executing the Command, the GPF shall be capable of sending such value(s) in a
Response.
573
4.5.4.7
574
A Command to remove Security Credentials for a Device from the GPF Device Log(4.6.2.3).
575
In executing the Command the GPF shall be capable of:
i.
Read GPF Constant Data
Read GPF Operational Data
Remove GPF Device Security Credentials
576
577
578
generating and sending an Alert to this effect, including details of the revised GPF
Device Log(4.6.2.3), via the WAN Interface; and
recording the Command and Outcome to the GPF Security Log(4.6.3.11).
ii.
579
4.5.4.8
580
A Command to replace GPF Security Credentials(4.6.2.4) held within the GPF.
581
In executing the Command the GPF shall be capable of:
Replace GPF Security Credentials
maintaining the Command’s Transactional Atomicity; and
recording the Command and Outcome to the GPF Security Log(4.6.3.11).
582
583
i.
ii.
584
4.5.4.9
585
A Command to restore the details in the GPF Device Log(4.6.2.3).
586
587
In executing the Command, the GPF shall be capable of recording the Command and
Outcome to the GPF Security Log(4.6.3.11).
588
4.5.4.10 Restrict GPF Data
589
590
591
A Command to restrict provision to Type 1 Devices and Type 2 Devices of all items of
Personal Data stored in the GPF which have a UTC date and time stamp prior to the date
and time stamp specified in the Restrict GPF Data Command.
592
4.6 Data Requirements
593
594
This section describes the minimum information which the CH shall be capable of holding in
its Data Store.
595
4.6.1 Constant Data
596
Describes data that remains constant and unchangeable at all times.
597
4.6.1.1
598
599
A globally unique identifier used to identify the CHF based on the EUI-64 Institute of
Electrical and Electronics Engineers (IEEE) standard.
600
4.6.1.2
601
An identifier used to identify the manufacturer of the CH.
602
4.6.1.3
603
An identifier used to identify the model of the CH.
Restore GPF Device Log
CHF Identifier
CH Manufacturer Identifier
Model Type
Version 1.47
18 November 2015
Page 21
DRAFT
CHTS
604
4.6.1.4
605
606
A globally unique identifier used to identify the GPF based on the EUI-64 Institute of
Electrical and Electronics Engineers (IEEE) standard.
607
4.6.2 Configuration Data
608
Describes data that configures the operation of various functions of the CH.
609
4.6.2.1
610
611
The Security Credentials for each of the Type 1 Devices, Type 2 Devices, GSME, ESME
and GPF with which the CHF can establish Communications Links.
612
4.6.2.2
613
614
The Security Credentials for the CHF and parties Authorised to establish Communications
Links with it.
615
4.6.2.3
616
617
The Security Credentials for each of the Type 1 Devices and Type 2 Devices with which the
GPF can establish Communications Links.
618
4.6.2.4
619
620
The Security Credentials for the GPF and parties Authorised to establish Communications
Links with it.
621
4.6.3 Operational Data
622
Describes data used by the functions of the CHF and GPF for output of information.
623
4.6.3.1
624
The Clock’s date and time (in UTC and Local Time).
625
4.6.3.2
626
627
A store holding, for each Device in the CHF Device Log(4.6.2.1), the UTC date and time of
the last Communications Link established with the CHF.
628
4.6.3.3
629
630
631
A log capable of storing one hundred UTC date and time stamped entries of non-security
related information for diagnosis and auditing, arranged as a circular Buffer such that when
full, further writes shall cause the oldest entry to be overwritten.
632
4.6.3.4
633
The active version of Firmware of the CHF and the GPF.
634
4.6.3.5
635
636
637
A log capable of storing one hundred UTC date and time stamped entries of security related
information for diagnosis and auditing, arranged as a circular Buffer such that when full,
further writes shall cause the oldest entry to be overwritten.
638
4.6.3.6
639
A store capable of holding the following values:
640
641
642
643
644
645
i.
ii.
iii.
GPF Identifier
CHF Device Log
CHF Security Credentials
GPF Device Log
GPF Security Credentials
CHF Date and Time
CHF Communications Store
CHF Event Log
CH Firmware Version
CHF Security Log
GPF Cumulative and Historical Value Store [INFO]
9 Days of Energy Consumption comprising the current Day and the prior 8 Days, in
kWh and Currency Units;
6 Weeks of Energy Consumption comprising the current Week and the prior 5
Weeks, in kWh and Currency Units; and
14 months of Energy Consumption comprising the current month and the prior 13
months, in kWh and Currency Units.
Version 1.47
18 November 2015
Page 22
DRAFT
CHTS
646
4.6.3.7
647
648
649
A log capable of storing 731 date stamped entries of Gas Consumption arranged as a
circular Buffer such that when full, further writes shall cause the oldest entry to be
overwritten.
650
4.6.3.8
651
652
653
A log capable of storing one hundred UTC date and time stamped entries of non-security
related information for diagnosis and auditing, arranged as a circular Buffer such that when
full, further writes shall cause the oldest entry to be overwritten.
654
4.6.3.9
655
656
657
A log capable of storing UTC date and time stamped entries of the GSME Constant Data,
GSME Configuration Data and GSME Operational Data except for the following SMETS
items:
658
659
660
661
662
663
664
665
666
i.
ii.
iii.
iv.
v.
vi.
vii.
viii.
ix.
GPF Daily Gas Consumption Log [INFO]
GPF Event Log
GPF GSME Proxy Log
Alerts Configuration Settings;
Device Log;
GSME Security Credentials;
GSME Identifier;
Public Key Security Credentials Store;
Supply Depletion State;
Supply Tamper State;
Uncontrolled Gas Flow Rate; and
Network Data Log.
667
4.6.3.10 GPF Profile Data Log [INFO]
668
669
670
A log capable of storing a minimum of 13 months of UTC date and time stamped half hourly
Gas Consumption data arranged as a circular Buffer such that when full, further writes shall
cause the oldest entry to be overwritten.
671
4.6.3.11 GPF Security Log
672
673
674
A log capable of storing one hundred UTC date and time stamped entries of security related
information for diagnosis and auditing, arranged as a circular Buffer such that when full,
further writes shall cause the oldest entry to be overwritten.
Version 1.47
18 November 2015
Page 23
DRAFT
CHTS
675
5 Glossary
676
Accumulated Debt Register
677
678
The information held on GSME as described at section 4 in the Smart Metering Equipment
Technical Specifications.
679
Active Tariff Price
680
681
The information held on GSME as described at section 4 in the Smart Metering Equipment
Technical Specifications.
682
Alert
683
684
A message generated by a Device including in response to a problem or the risk of a
potential problem.
685
Authentication
686
687
The method used to confirm the identity of entities or Devices wishing to communicate and
‘Authenticated’ and ‘Authenticity’ shall be construed accordingly.
688
Authorisation
689
690
The process of granting access to a resource and ‘Authorised’ shall be construed
accordingly.
691
Block Pricing
692
693
A pricing scheme used in conjunction with Time-of-use Pricing where Price varies based on
Consumption over a given time period.
694
Buffer
695
An area of the CH capable of storing information for Buffering.
696
Buffering
697
Temporary storage of information pending it being forwarded via the HAN or WAN Interface.
698
Calorific Value
699
700
The information held on GSME as described at section 4 in the Smart Metering Equipment
Technical Specifications.
701
Certificate
702
703
An electronic document that binds an identity, and possibly other information, to a Public
Key.
704
Certificate Signing Request
705
A message requesting the issue of a Certificate by a Certification Authority.
706
Certification Authority (CA)
707
A trusted entity which issues Certificates.
708
CESG
709
The UK Government's national technical authority for information assurance.
710
Clock
711
A timing mechanism that has a minimum resolution of 1 second.
712
Command
713
An instruction to perform a function received or sent via any interface.
Version 1.47
18 November 2015
Page 24
DRAFT
CHTS
714
Commercial Product Assurance Security Characteristic for GB Smart Metering
715
716
717
The document forming part of the Smart Energy Code describing the requirements for
evaluation and certification of Communications Hubs under CESG’s Commercial Product
Assurance scheme.
718
Communications Hub Function (CHF)
719
720
The functionality in the CH specific to its operation as a bridge between the WAN Interface
and HAN interface.
721
Communications Link
722
723
724
The exchange of Commands, Responses, Alerts and other information between a system or
Device and another system or Device which is independent of the transport mechanism
used.
725
Confidentiality
726
727
The state of information, in transit or at rest, where there is assurance that it is not
accessible by Unauthorised parties through either unintentional means or otherwise.
728
Consumer
729
A person who lawfully resides at the Premises that is being Supplied.
730
Consumption
731
Gas Consumption or Electricity Consumption information.
732
Consumption Register
733
734
The information held on GSME as described at section 4 in the Smart Metering Equipment
Technical Specifications.
735
Contact Details
736
737
The information held on GSME as described at section 4 in the Smart Metering Equipment
Technical Specifications.
738
Conversion Factor
739
740
The value held on GSME as described at section 4 in the Smart Metering Equipment
Technical Specifications.
741
Critical Command
742
743
Those Commands which relate to Supply being affected, financial fraud or the compromise
of the security of Devices in Consumer Premises.
744
Cryptographic Algorithm
745
746
747
An algorithm for performing one or more cryptographic functions which may include:
Encryption, Decryption, Digital Signing or Hashing of information, data, or messages; or
exchange of Security Credentials.
748
Currency Units
749
The units of monetary value in major and minor units.
750
Customer Identification Number
751
752
The information held on GSME as described at section 4 in the Smart Metering Equipment
Technical Specifications.
753
Data and Communications Company
Version 1.47
18 November 2015
Page 25
DRAFT
CHTS
754
755
756
The holder of the licence for the provision of a smart meter communication service granted
pursuant to section 6(1)(f) or 6(1A) of the Electricity Act 1989 or section 7AB of the Gas Act
1986.
757
Data Integrity
758
759
The state of data where there is assurance that it has not been altered by Unauthorised
parties.
760
Data Store
761
An area of the CH capable of storing information for future retrieval.
762
Day
763
The period commencing 00:00:00 Local Time and ending at the next 00:00:00.
764
Debt Recovery per Payment
765
766
The information held on GSME as described at section 4 in the Smart Metering Equipment
Technical Specifications.
767
Debt Recovery Rates [1 … 2]
768
769
The information held on GSME as described at section 4 in the Smart Metering Equipment
Technical Specifications.
770
Debt Recovery Rate Cap
771
772
The information held on GSME as described at section 4 in the Smart Metering Equipment
Technical Specifications.
773
Debt to Clear
774
775
The information held on GSME as described at section 4 in the Smart Metering Equipment
Technical Specifications.
776
Decryption
777
778
The process of converting Encrypted information by an Authorised party to recover the
original information and like terms shall be construed accordingly.
779
Device
780
GSME, ESME, a GPF, a CHF, a Type 1 Device or a Type 2 Device.
781
Device Commissioning Alert
782
An Alert sent by a Device as part of the process of bringing that Device into operation.
783
Digital Signature
784
785
786
787
The information appended to a message which is created using the sender’s Private Key,
can be verified using the Public Key contained in the sender’s Certificate and provides the
receiver with assurance that the sender is who they claim to be, the message is as sent by
the sender and that the sender sent the message.
788
Digital Signing
789
The creation of a Digital Signature.
790
Disablement Threshold
791
792
The information held on GSME as described at section 4 in the Smart Metering Equipment
Technical Specifications.
793
Electricity Consumption
794
As described at section 5 in the Smart Metering Equipment Technical Specifications.
Version 1.47
18 November 2015
Page 26
DRAFT
CHTS
795
Elliptic Curve DSA
796
797
The Elliptic Curve Digital Signature Algorithm forming part of the NSA Suite B standard (see
http://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml).
798
Elliptic Curve DH
799
800
The Elliptic Curve Diffie–Hellman Algorithm forming part of the NSA Suite B standard (see
http://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml).
801
Emergency Credit Balance
802
803
The information held on GSME as described at section 4 in the Smart Metering Equipment
Technical Specifications.
804
Emergency Credit Limit
805
806
The information held on GSME as described at section 4 in the Smart Metering Equipment
Technical Specifications.
807
Emergency Credit Threshold
808
809
The information held on GSME as described at section 4 in the Smart Metering Equipment
Technical Specifications.
810
Encryption
811
812
The process of converting information in order to make it unintelligible other than to
Authorised parties and like terms shall be construed accordingly.
813
Energy Consumption
814
The amount of gas in kWh Supplied to the Premises.
815
ESME
816
Electricity Smart Metering Equipment as described in the SMETS.
817
Firmware
818
The embedded Software programmes and / or data structures that control Devices.
819
Gas Consumption
820
821
The volume of gas in cubic metres (m3) Supplied to the Premises and “Consumed” shall be
construed accordingly.
822
Gas Proxy Function (GPF)
823
824
The functionality in the CH specific to its operation as a store of GSME data and associated
data.
825
Great Britain Companion Specification
826
827
828
829
The document forming part of the Smart Energy Code describing the nature of
Communications Links that the CH must be capable of forming via the HAN Interface and
the WAN Interface. The current version of Great Britain Companion Specification can be
found here: https://www.smartenergycodecompany.co.uk/sec/the-developing-sec
830
GSME
831
Gas Smart Metering Equipment as described in the SMETS.
832
GSME Activate Emergency Credit Command
833
834
A Command to activate Emergency Credit as described at section 4 in the Smart Metering
Equipment Technical Specifications
835
GSME Add Credit Command
Version 1.47
18 November 2015
Page 27
DRAFT
CHTS
836
837
A Command to accept credit to be applied to GSME as described at section 4 in the Smart
Metering Equipment Technical Specifications
838
GSME Billing Data Log
839
840
The data held on GSME as described at section 4 in the Smart Metering Equipment
Technical Specifications.
841
GSME Calorific Value
842
843
The data held on GSME as described at section 4 in the Smart Metering Equipment
Technical Specifications.
844
GSME Configuration Data
845
846
The data held on GSME as described at section 4 in the Smart Metering Equipment
Technical Specifications.
847
GSME Consumption Register
848
849
The data held on GSME as described at section 4 in the Smart Metering Equipment
Technical Specifications
850
GSME Constant Data
851
852
The data held on GSME as described at section 4 in the Smart Metering Equipment
Technical Specifications.
853
GSME Conversion Factor
854
855
The data held on GSME as described at section 4 in the Smart Metering Equipment
Technical Specifications.
856
GSME Cumulative and Historical Value Store
857
858
The data held on GSME as described at section 4 in the Smart Metering Equipment
Technical Specifications.
859
GSME Cumulative Current Day Value Store
860
861
The data held on GSME as described at section 4 in the Smart Metering Equipment
Technical Specifications.
862
GSME Operational Data
863
864
The information held on GSME as described at section 4 in the Smart Metering Equipment
Technical Specifications.
865
GSME Profile Data Log
866
867
The information held on GSME as described at section 4 in the Smart Metering Equipment
Technical Specifications.
868
GSME Tariff Block Counter Matrix
869
870
The information held on GSME as described at section 4 in the Smart Metering Equipment
Technical Specifications
871
GSME Tariff TOU Register Matrix
872
873
The information held on GSME as described at section 4 in the Smart Metering Equipment
Technical Specifications
874
Hashing
875
876
A repeatable process to create a fixed size and condensed representation of a message of
any arbitrary data. Hash and like terms shall be construed accordingly.
877
Home Area Network Interface (HAN Interface)
Version 1.47
18 November 2015
Page 28
DRAFT
CHTS
878
879
A component of the CH that is capable of sending and receiving information to and from
other Devices.
880
Inter-PAN
881
A lower-layer communications mechanism.
882
Intimate Physical Interface
883
884
A standardised interface defined by the Data and Communications Company, which includes
provision for the DC power supply to the CH.
885
Key
886
Data used to determine the output of a cryptographic operation.
887
Key Agreement
888
A means to calculate a shared Key between two parties.
889
Local Time
890
The UTC date and time adjusted for British Summer Time.
891
Low Credit Threshold
892
893
The information held on GSME as described at section 4 in the Smart Metering Equipment
Technical Specifications.
894
Message Authentication
895
896
The process by which the receiver of a message is provided with assurance that the sender
is who they claim to be and that the message is in the form originally sent.
897
Meter Balance
898
899
The information held on GSME as described at section 4 in the Smart Metering Equipment
Technical Specifications.
900
Meter Point Reference Number (MPRN)
901
902
The information held on GSME as described at section 4 in the Smart Metering Equipment
Technical Specifications.
903
Non-Disablement Calendar
904
905
The information held on GSME as described at section 4 in the Smart Metering Equipment
Technical Specifications.
906
Outcome
907
The result of executing a Command, expressed as success or failure.
908
Payment Debt Register
909
910
The information held on GSME as described at section 4 in the Smart Metering Equipment
Technical Specifications.
911
Payment Mode
912
913
The information held on GSME as described at section 4 in the Smart Metering Equipment
Technical Specifications.
914
Personal Data
915
916
Any information comprising Personal Data as such term is defined in the Data Protection Act
1998 at the date the CHTS is brought into force.
917
Premises
Version 1.47
18 November 2015
Page 29
DRAFT
CHTS
918
The premises which is Supplied.
919
Price
920
921
The value held on GSME as described at section 4 in the Smart Metering Equipment
Technical Specifications.
922
Private Key
923
924
The key in a Public-Private Key Pair which must be kept secure by the entity to which it
relates.
925
Profile Data Log
926
927
The information held on GSME as described at section 4 in the Smart Metering Equipment
Technical Specifications.
928
Public Key
929
The key in a Public-Private Key Pair which can be distributed to other parties.
930
Public-Private Key Pair
931
Two mathematically related numbers that are used in Cryptographic Algorithms.
932
Random Number Generator
933
934
A component used to generate a sequence of numbers or symbols that lack any predictable
pattern.
935
Replay Attack
936
937
A form of attack on a Communications Link in which a valid information transmission is
repeated through interception and retransmission.
938
Response
939
940
Sent on, or received from the User Interface or HAN Interface or any other interface
containing information in response to a Command.
941
Role
942
The entitlement of a party to execute one or more Commands.
943
SECAS
944
The Smart Energy Code Administrator and Secretariat.
945
Secure Perimeter
946
A physical border surrounding the CH.
947
Security Credentials
948
Information used to identify and / or Authenticate a Device, party or system.
949
Sensitive Event
950
Each of the following events:
951
952
i.
ii.
a failed Authentication or Authorisation; and
a change in the executing Firmware version.
953
SHA-256
954
955
The Hashing algorithm of that name approved by the NIST (see
http://csrc.nist.gov/groups/ST/toolkit/secure_hashing.html).
956
Smart Metering Equipment Technical Specifications (SMETS)
Version 1.47
18 November 2015
Page 30
DRAFT
CHTS
957
958
The document brought into force by the Secretary of State to describe the minimum
capabilities of equipment installed to satisfy the roll-out licence conditions.
959
Smart Metering Home Area Network
960
A communications network allowing the exchange of information between Devices.
961
Software
962
The software programmes and / or data structures that control the GPF.
963
Standing Charge
964
965
The value held on GSME as described at section 4 in the Smart Metering Equipment
Technical Specifications.
966
Supplier Message
967
968
The information held on GSME as described at section 4 in the Smart Metering Equipment
Technical Specifications.
969
Supply
970
The supply of gas to Premises for GSME and ‘Supplied’ shall be construed accordingly.
971
Supply State
972
973
The information held on GSME as described at section 4 in the Smart Metering Equipment
Technical Specifications.
974
Tariff Block Counter Matrix
975
976
The matrix held on GSME as described at section 4 in the Smart Metering Equipment
Technical Specifications.
977
Tariff Switching Table
978
979
The information held on GSME as described at section 4 in the Smart Metering Equipment
Technical Specifications.
980
Tariff Threshold Matrix
981
982
The information held on GSME as described at section 4 in the Smart Metering Equipment
Technical Specifications.
983
Tariff TOU Price Matrix
984
985
The matrix held on GSME as described at section 4 in the Smart Metering Equipment
Technical Specifications.
986
Tariff TOU Register Matrix
987
988
The matrix held on GSME as described at section 4 in the Smart Metering Equipment
Technical Specifications.
989
Time Debt Registers [1 … 2]
990
991
The information held on GSME as described at section 4 in the Smart Metering Equipment
Technical Specifications.
992
Transactional Atomicity
993
The type and order of the constituent parts of a Command.
994
Trusted Source
995
A source whose identity is confidentially and reliably validated.
996
Type 1 Device
Version 1.47
18 November 2015
Page 31
DRAFT
997
998
999
CHTS
A Device, other than GSME, ESME, Communications Hub Function or Gas Proxy Function,
that stores and uses the Security Credentials of other Devices for the purposes of
communicating with them via its HAN Interface.
1000
Type 2 Device
1001
1002
A Device that does not store or use the Security Credentials of other Devices for the
purposes of communicating with them via its HAN Interface.
1003
Unauthorised
1004
Not Authorised.
1005
Unauthorised Physical Access
1006
Unauthorised access to the internal components of the CH through its Secure Perimeter.
1007
UTC
1008
Coordinated Universal Time.
1009
Wide Area Network (WAN) Interface
1010
1011
A component of CH that is capable of sending and receiving information via the Wide Area
Network Provider.
1012
Wide Area Network Provider
1013
The organisation providing communications over the WAN Interface.
1014
Week
1015
1016
The seven day period commencing 00:00:00 Monday Local Time and ending at 00:00:00 on
the immediately following Monday.
1017
ZigBee Smart Energy Profile (SEP) Version 1.2
1018
1019
The ZigBee Smart Energy Profile Specification 1.2a v1.0 (reference 07-5356r19:
http://zigbee.org/About/GBCSPartner.aspx).
1020
Version 1.47
18 November 2015
Page 32
DRAFT
1021
CHTS
This page is intentionally left blank.
Version 1.47
18 November 2015
Page 33
Crown copyright 2015
Department of Energy & Climate Change
3 Whitehall Place
London SW1A 2AW
www.gov.uk/decc
URN 15D/502
Download