SEC Working Group 4 – Meeting 2
3rd June 2016
Minutes
Attendees:
Working Group 4 Members
Organisation
Gerard Masterson
British Gas
David Lyons (Mod 13 Proposer
Representative)
EOn
Nick Jones (Mod 12 Proposer)
Siemens
Adrian van den Heever
Geotogether
Elias Hanna
Landis Gyr
Other Attendees:
Name
Representing
Eric Taylor
Adam Pearce
DCC
Edward Mace
Adam Lattimore (Chair)
Urszula Thorpe(Technical Support)
David Barber (Modifications Lead)
SECAS
Keith Phakoe (Meeting
Secretary/Modifications Analyst)
James Gorie
DECC
Apologies:
Working Group 4 Members
Graham Wood (SECMP0010 Proposer)
Organisation
British Gas
SECMP0010 - Introduction of triage arrangements
for Communication Hubs
1
Introductions/Objectives
The Chair introduced the attendees and then laid out the objectives of the second Working
Group meeting for this Modification. These were to:

Discuss the Business Requirements document

Review the Business process put forward to accompany the Requirements identified

Answer any questions/points of clarification arising from the above discussions

Agree a solution and a set of refined Business Requirements
Business Requirements
The Business Requirements identified from the first meeting were presented on a slide.
Refined versions of these are available on a separate document. Discussion centred on
each Business Requirement.
BR01 - In the case of unsuccessful CH installations, DCC to provide Suppliers
with means of testing the device “health”.
A Supplier said failures could be attributed to Hardware or Firmware. DCC pointed out that
some defects can only be found in the field. The question should always be ‘why has this
installation failed?’ and the need is to find out there and then. Therefore, this solution would
need to be available in the field.
DECC asked if a Service Request (SR) might be a possible method of diagnosing the fault.
DCC replied that SRs are only really appropriate if you know what you are looking for. The
CH may not be the problem, or it may be a problem that has never been encountered
before. Triage can reproduce the fault for diagnosis, which SRs may not be able to identify.
A Manufacturer wondered whether receiving and/or interpreting error responses from
corresponding SRs in the field would present a problem. DCC replied that it is necessary to
expose the information relevant to the issue from the CH. This is hard to do outside the test
environment, although using a hand held device might be possible.
A Supplier pointed out meter operatives would need to be trained to interpret the output of
triage, or any other solution that this Modification explores during the Refinement process.
This would help with eliminating the return of the 80% of Hubs that are not defective (this is
believed to be the number that get sent back unnecessarily). It was clarified that the scope of
this Modification is limited to analysing the outputs of triage. Fixing faults in the field is not in
scope.
The Supplier also added that the scope of this Modification does not extend to Devices other
than the CH . Triage and installation of other Devices is being dealt with by SECMP0013,
and this Modification only deals with CH installation, not asset management, and is to do
with CH triage, not testing.
The scope of the Modification mentioned in these two points has subsequently been noted
as something to be refined. The refined scope is part of the updated Business
Requirements.
BR02 - In the case of unsuccessful CH installations, DCC to provide Suppliers
with means of testing the presence/absence of private information.
A Supplier noted that there could be more than personal data on the CH. The Supplier asked
that if that was the case, was it safe to reset the CH all the time to remove information
(personal or otherwise) from it? DCC pointed out that rather than resetting the CH it is
believed to be cheaper to clean out only the data you need to remove, since by applying a
factory reset Organisational Certificates and CHF’s Private Keys on the Communications
Hub Function (CHF) would be removed. Such CHs would need to be returned to the DCC to
populate the relevant Organisational Certificates on the CHF and regenerate CHF’s Private
Keys, which would increase the cost.
DCC further noted that the solution will mainly be used either on delivery of the CH to
Suppliers and/or during the commissioning of the Smart Metering System at the site, or if a
Device forming part of a Smart Metering System need to be replaced (meter exchange due
to failure etc.)
DCC were asked why DCC cannot provide a full reset, and whether a factory reset should
be done by Suppliers in the field. There was a suggestion of a 3 x 2 matrix where:

LOCATIONS would be:
1. In the field
2. An asset centre
3. A secure asset centre (with raised security standards)

STATUSES would be:
1. Can it be reused? (binary options)
2. Can it be reset in the field/Asset centre/secure asset centre?
Actions/Possible new Business Requirements
A request was made to invite more Suppliers to the next meeting. However, it was noted that
the WG4 members included other Suppliers. They are receiving the outputs from the WG
meetings and have the opportunity to input, even though they may not be able to attend the
actual meetings.
DCC was asked to feedback regarding what CH triage/diagnostics they can offer to Supplier
if such triage/diagnosis is performed in an Asset Centre (secured or otherwise) and what
diagnostics/triage can be offered to Suppliers on site. (the matrix mentioned in BR3 above).
This will fall out from the DCC PA, and will be part of the request that is issued.
DCC/Suppliers to investigate what requirements surround the other elements of the status
matrix.
SECMP0013 - Smart meter device diagnostics
and triage
Overview of Modification Proposal
The Proposer explained that in SMETS1, Suppliers noted that there was a problem with
smart metering devices returned to the warehouse by meter installers. Namely, that in 50%
of cases no fault was found with the meter.
The reason for the modification was that currently there is no provision in the SEC to test
whether SMETS2 devices can form part of a Smart Metering System and communicate with
the DCC. The suggestion is for a replication of SMETS1 functionality.
Working Group consideration of Modification Proposal
The Working Group’s first observation is that this is definitely to be used in the live
environment (production only). The Working Group clarified that this should apply to any
Device (except CHs which are covered in SECMP0010), and DCC should provide test CHs
to support such testing.
The Proposer suggested that the task be split into two parts:


first, triage at the Goods Inward stage (effectively augmenting SECMP0010), and
second, communicating with the DCC, possibly in an external lab.
The Proposer suggested that if the Modification was not done, it could cost the industry an
extra £50 million (if not added to the original Smart Meter Rollout costing).
The DCC confirmed that the scope of the triage would be to recreate a scenario that
replicated the customer’s property, but would not be HAN compatibility testing. The DCC
asked if it needed to replicate normal use, and whether certain data needed to be tagged.
Manufacturers pointed out several issues that they felt the DCC and the Proposer needed to
address.
1. In general this may present a lot of issues for Manufacturers. For example, there was no
lock/unlock command on devices because TSEG were unable to get Supplier support
when this was discussed.
2. Doing any ‘goods inward’ testing would leave information on the device. There was a
lack of clarity as to whether the Supplier could install the device afterwards, or whether it
would need to go back to the Manufacturer.
3. Mention was made of the possibility of some kind of clear down mechanism that the
testing process could incorporate which would mean that Devices would be able to reused in the field, without the need to go back to manufacturers. There would be some
account taken of the number of devices Suppliers were willing to write off for testing
purposes.
4. They wanted to be able to pretend they were in a customer’s property, and wanted to
know if DCC could provide this capability currently.
DCC and the Proposer replied as follows.




They pointed out that assets in SMETS1 get reused after testing already, and this was
just a continuation of that functionality. There was no issue as far as they could see with
devices after testing. The triage scenario could be done in an exterior lab.
The suggestion was made that to avoid the issues around information being left on a
device and making it subsequently inoperable, the triage should use dummy MPXN
information. This dummy information could be cleared down after triage with no
consequences.
It was flagged that such an approach would require investigation as to whether it was
possible, and what the impacts would be on other Codes, as the assigning of MPXNs is
dealt with under other code provisions.
The Proposer outlined the two current processes used for triage, summarised in the
diagrams below, and where the SECMP0013 solution could slot in to support the
activities undertaken. The Returns process led to the creation of a Business
Requirement where it was possible to execute a forced disassociate of the HAN and
clear down of the data on the device, including factory reset if needed.
Goods Inward
(Quality Assurance sampling)
Outcomes
Pass
Can be used
Fail
Return to Manufacturer
Returns


The question arose about churned meters being brought back to the Supplier for triage, and why dummy MPXNs were being pushed as
being part of the solution in light of this.
Working Group members requested a definitive list of what was being cleared down from the meters, as there may be security issues around
clear down, and Binding needs a specific set of actions on clear down.
SECMP0012 - Channel selection to support
Shared HAN solutions
Overview of Modification Proposal
Time constraints meant that this Modification was only discussed in outline terms. The
Proposer explained the purpose of the Modification. He stressed the risk associated with not
having a solution in place for ensuring channels were available for switching where
necessary.
Working Group consideration of Modification Proposal
A Supplier pointed out that seeking to set channel selection at 2.4GHz for shared HAN
infrastructure where the density of buildings and housing caused a problem with signals was
part of the ongoing Alternative HAN work being discussed elsewhere. These include this
Procurement Request For Information (RFI). The outcome of these discussions may inform
the further shaping of this Modification, and are expected to be complete in or around July
2016. The Proposer stressed that regardless of those discussions CH manufacturers still
needed to be able to select the 2.4GHZ frequency to adequately compete in an open market
for Alternative HAN provision solutions.
A Manufacturer pointed out that even if there was a provision made to enable channel
switching and to steer CHs to reserved channels, there was an issue regarding other users
of that frequency. It was suggested that even if all CH users and parties were willing to avoid
using a channel reserved for someone else there was nothing to stop others who were not
party to any agreement using that channel. Legislation would be required to reserve a
channel and stop others using that frequency. It was agreed that this point would be taken
away and considered as part of a refined solution.
The Proposer pointed out that not extending channel selection to 2.4GHz in an industry that
has recognised the importance of shared HAN technologies in delivering smart metering, will
result in sub-optimal solutions.
DCC and a Supplier answered that until the Alternative HAN discussions were concluded it
would be very difficult to make any assurances about the way forward in terms of channel
selection on the 2.4GHz channel.
Actions
From these preliminary discussions, the following actions emerged.
1
2
3
DCC/Proposer to have further discussions and report back, and address:
i. A mechanism to steer CHs to selected/reserved channels
ii. Whether or not this needs to be actioned before the RFI.
SECAS to prepare Business Requirements based on this output.
SECAS to monitor output of Alternative HAN Procurement RFI and report
back.
Next Meeting
TBC