Study on ensuring interoperability for enabling Demand Side Flexibility.
Date: 2019-07-03
Institutions: Directorate-General for Communications Networks, Content and Technology
Subjects: electrical energy, energy demand, energy supply, information technology, soft energy, sustainable development

Ref. Ares(2019)27592 - 04/01/2019

Study on ensuring 
interoperability for 
enabling Demand 
Side Flexibility 

EXECUTIVE SUMMARY 

A study prepared for the European Commission 
DG Communications Networks, Content & Technology 
by: 

Digital 
Single 
Market 

 
 
 
 
 
 
 
 
 
 
 
 
 
This study was carried out for the European Commission by 

Auteurs:  

Laura Daniele, TNO  

Laura.Daniele@tno.nl 

Willem Strabbing, ESMIG  

wstrabbing@esmig.eu 

Bas Roelofsen, DNV-GL  

Bas.Roelofsen@dnvgl.com 

Arjan Aalberts, DNV-GL  

Arjan.Aalberts@dnvgl.com 

Paul Stapersma, TNO  

Paul.Stapersma@tno.nl 

Internal identification 

Contract number: 30-CE-0837391/00-82  
SMART number 2016/0082 

DISCLAIMER 

By the European Commission, Directorate-General of Communications Networks, Content & Technology.  

The information and views set out in this publication are those of the author(s) and do not necessarily reflect 
the official opinion of the Commission. The Commission does not guarantee the accuracy of the data included in 
this study. Neither the Commission nor any person acting on the Commission’s behalf may be held responsible 
for the use which may be made of the information contained therein. 

ISBN 978-92-79-91236-8 

doi: 10.2759/26799 

© European Union, 2018. All rights reserved. Certain parts are licensed under conditions to the EU.  

Reproduction is authorised provided the source is acknowledged. 

 
 
 
 
 
 
 
 
 
 
Abstract 
The transition to sustainable energy sources introduces distributed intermittent energy that requires 
more  flexibility  in  demand.  It  is  anticipated  that  consumers  will  play  an  active  role  with  self-
generation  and  will  pro-actively  manage  their  demand  according  to  their  needs  and  available 
resources; this is called Demand Side Flexibility (DSF). Energy Management applications will be used 
to  control  consumption,  generation  and  storage,  so  that  consumers  will  be  in  control,  but  will  not 
need  to  execute  all  the  related  actions  themselves.  These  applications  will  take  input  from  Smart 
Meters and signals from energy market players to control the in-home energy flows. To that end, the 
data  needed  for  DSF  needs  to  flow  seamlessly  through  an  IT  infrastructure  that  connects  Smart 
Meters,  Consumer  Energy  Management  Systems,  Smart  Appliances  and  Gateways  between  the 
home and external networks. The IT infrastructure of DSF is covered by three different industries that 
all  have  separately  developed  technology  and  standards,  i.e.,  the  Utility  industry,  the  Telecom 
industry  and  the  Home  appliances  industry.  Originated  for  different  purposes  and  in  different 
context, the communication standards from these industries are not necessarily aligned, leading to 
barriers in the seamless flow of data in the DSF infrastructure. 

In this study, we have investigated the need for alignment among the communication standards from 
the  Utility,  Telecom  and  Home  appliances  industries.  We  have  selected  nine  standards  that  have 
been  compared  with  the  reference  ontology  SAREF  (Smart  Appliances  REFerence  ontology), 
developed  in  an  earlier  project  commissioned  by  DG-Connect,  and  its  extension  for  the  Energy 
domain,  SAREF4ENER.  We  concluded  that  alignment  between  DSF  standards  is  needed  and  that 
SAREF/SAREF4ENER  can  be  used  as  the  overarching  ontology  to  facilitate  this  alignment.  Several 
actions  and  recommendations  for  various  stakeholders,  such  as  the  Standards  Development 
Organisations, have been identified and are listed in the report.  Moreover, a proof of concept was 
demonstrated to show DSF interoperability through the complete, end-to-end IT infrastructure, from 
Smart Grid to Smart Meters and Smart Appliances. The next step to be taken is to scale up the proof 
of  concept  that  we  demonstrated,  implementing  the  resulting  SAREF-based  solution  in  more  use 
cases for Demand Side Flexibility, in more smart devices and at real consumer sites.  

Digital 
Single 
Market 

 
 
 
 
 
 
 
 
Executive Summary 

The Background 

The energy transition can generally be described as the shift from power generation with fossil fuels 
(oil, coal, natural gas) to renewable energy sources such as wind, solar power, geothermal and ocean 
power. The nature of renewable energy sources, unlike conventional power generation, is that they 
are  intermittent,  meaning  that  they  are  not  continuously  available  to  meet  the  demand.  Since  our 
society is very dependent on access to an uninterrupted power supply, implementation of renewable 
energy requires an intelligent energy system to cope with intermittent energy sources by balancing 
electricity demand and supply. 

Balancing  electricity  will  require  flexibility  on  both  the  demand  and  supply  sides,  requiring 
interconnection, storage, flexible generation, and flexible demand. Flexibility on the demand side is 
necessary as flexibility on the supply side is limited, increasing generation may take too much time or 
it may be too expensive to operate, and demand can at times exceed the total generation capacity. 
In this study the flexibility of energy demand is studied.  

Demand  Side  Flexibility  (DSF) 
is  the  ability  of 
consumers  to  adapt  their  electricity  consumption  in 
response  to  market  signals.  The  end-consumer  may 
adjust power demand by postponing some tasks that 
require  large  amounts  of  electric  power,  or  may 
decide to pay a higher price for their electricity.  

in  principle  be 

End-consumers  can 
industrial 
consumers  or  residential  consumers.  However,  this 
study  explicitly  focusses  on  residential  consumers 
and thus on residential demand side flexibility. 

residential  end-consumer 

requires  power 
The 
demanding  appliances  that  offer  flexibility.  For 
instance,  postponing  the  operation  of  a  washing 
machine  shifts  the  power  demand  and  thus  offers 
flexibility  to  the  energy  company.  Other  examples 
are  provided  by  home  appliances  such  as  heat 
pumps,  Electric  Vehicle  (EV)  charging  stations  and  refrigerators.  Nowadays,  home  appliances  are 
highly intelligent (“smart”) and networked devices that form complete energy consuming, producing 
and managing systems, which can be controlled automatically through internet communication.  

Figure 0-1: Home configuration 

A  suitable  configuration  to  enable  and  realise  demand  side  flexibility  includes  a  number  of 
components,  such  as  smart  appliances  that  can  respond  to  market  signals,  an  in-home  energy 
management system that controls and monitors the smart appliances and communicates with the  

Digital 
Single 
Market 

 
 
 
 
 
energy companies, a smart meter for settlement purposes, and an in-home display for consumers to 
monitor what is happening in their home. Included in the demand side flexibility chain, but outside 
the residential premises, are the energy companies that push requests for flexibility. 

The Study 

An important condition for the introduction of demand side flexibility is that smart appliances, smart 
meters,  EV  charging  stations,  energy  management  systems,  etc.,  can  all  communicate  with  each 
other. In other words, the smart appliances and systems involved in the demand side flexibility chain 
need  to  be  interoperable  and  interoperability  is  fostered  when  the  communication  is  based  on 
standard interfaces.  

Alignment is needed because of the fragmentation and lack of harmonization among standards that 
have  been  developed  at  different  times  and  with  different  purposes  by  various  standards 
development  organisations  (SDOs)  active  in  the  telecom  industry,  utility  industry  and  home 
appliances industry. The European Commission therefore issued a tender for a study on  addressing 
the lack of interoperability in the end-to-end Demand-Side Flexibility flow, by identifying the need for 
alignment  between  data  standards  in  this  flow  and  providing  a  solution  for  several  relevant  use 
cases. 

TNO,  ESMIG  and  DNV  GL  were  invited  to  perform  this  study.  The  study  has  identified  gaps  in  the 
current standardisation landscape in the field of demand side flexibility, analysed alignments needed 
to  achieve  (semantic)  interoperability  on  data  level  using  SAREF  (a  reference  ontology  for  smart 
appliances  developed  in  an  earlier  project  promoted  by  DG-CNCT),  proposed  consequent  actions 
towards the realisation of these alignments, and demonstrated an integrated demand side flexibility 
infrastructure as a proof-of-concept of interoperability. 

The  scope  of  the  study  was  residential  consumers,  not  including  storage.  The  focus  was  on  smart 
appliances and the use of SAREF for DSF, where SAREF also studied residential consumers instead of 
industrial or commercial consumers. The use of storage in residential homes is out of scope for this 
study,  as  use  cases  and  data  definitions  are  under  development  and  therefore  are  considered  not 
mature yet. 

The Approach 

The first step was to identify on which data elements interoperability should be reached. Therefore, 
we have identified relevant use cases in the DSF domain and listed its associated data elements. In 
the  second  step,  we  identified  the  standards  that  cover  the  various  interfaces  of  the  DSF 
infrastructure.  Thirdly,  we  have  identified  the  alignments  needed  between  these  standards  on  the 
identified data elements. Finally, a proof-of-concept solution for alignment has been demonstrated. 

The  study  closely  involved  various  SDOs,  stakeholders  from  industry,  Utilities  and  the  European 
Commission at different stages, to be informed about the intermediate results, gather feedback and  

Digital 
Single 
Market 

 
 
 
 
 
assist to the final demonstration of the resulting integrated infrastructure for demand side flexibility. 
In this demonstration, the manufacturing industry clearly showed its intention to use the standards 
and  the  alignments  proposed  in  this  study  to  create  a  seamless  information  infrastructure  for 
demand  side  flexibility.  The  demonstration  took  place  at  three  different  venues,  namely  1)  the 
European  Utility Week  conference and  exhibition  in  Amsterdam,  3-5  October  2017,  2) the  ETSI IoT 
week in Sophia Antipolis, 23-26 October 2017, and 3) the DG-Connect’s premises in Brussels on 27-29 
November 2017. 

The Results 

The domain of demand side flexibility is broad in the sense that there is a large amount of use cases 
and  standards  that  cover  or  touch  upon  it.  Therefore,  a  sample  of  relevant  use  cases  has  been 
selected (10 use cases). The use cases and the extracted data elements are shown in the table below. 

Table 0-1: Selected use cases and the extracted DSF core data elements  

USE CASE 

DSF CORE DATA ELEMENTS 

Device Registration & Configuration 

-  Device Identifier 
-  Device capabilities 

Flexible start of Smart Device 

Flex start enabled  
Energy consumption  
Energy Profile 
Start time/ time slot of operation 

-  Control parameters, e.g. profile selection 
-  Preferred time slot of operation per Device 
- 
- 
- 
- 
-  New tariff information 
-  Recalculated start time / time slot 
-  Operation commands 

Response of Smart Home to Emergency 

- 
- 

Emergency signal 
Emergency load command 

Control of non-smart Device by CEM 

Direct Load Control of Smart Device via CEM 

- 
Tariff threshold 
-  Real Time Tariff 
-  Operation commands (increase or decrease power and turn 

off/on) 

Id of participating devices 

- 
-  Power thresholds 
- 
- 
- 
- 

Load management signal 
Load adjustment command 
Feedback about adjustment 
Expected change in consumption 

Demand-supply adjustment by cooperation between 
supplier and customer  

-  Price information of electrical energy based on time of use 

(TOU) 

-  Planned load profile (expected consumption in time) 

Exchanging information on (partial) consumption 

-  Actual Individual Appliances (= partial) consumption/generation 
- 

Forecasted partial consumption/generation 

Digital 
Single 
Market 

 
 
 
 
 
External Actor Retrieves status of smart devices 

-  Actual total house consumption 
- 

Forecasted total house consumption 

-  Device Status Request 
-  Device Status 
- 

Status is displayed to consumer 

CEM requests time from Smart Meter GW and Smart 
Meter GW synchronizes time of CEM 

-  Actual time request 
-  Actual time 

Smart Meter GW notifies actual tariff to CEM 

-  Active tariff notification 

We have further selected a sample of relevant standards that cover the interfaces of the DSF flow (10 
standards): 

  CEN 16836 (ZigBee SEP2) 
  CENELEC EN 50491-11 Smart Metering 
  CENELEC EN 50631-1 (SPINE) 
  ETSI TS 103 264 (SAREF) 
  ETSI TS 103 410-1 (SAREF4ENER) 
 
IEC 61968-9 CIM for metering 
 
IEC 61970 CIM  
 
IEC/CENELEC 62056 COSEM 
  CENELEC EN 50090 (KNX) 
  oneM2M TS 0012 Base Ontology 

The  SAREF  and  SAREF4ENER  ontologies  have  been  used  as  the  overarching  ontologies  to  make 
if  the  considered  standards  could  be  aligned  with 
alignments  on  the  assumption  that, 
SAREF/SAREF4ENER  on  the  core  data  elements  in  the  DSF  domain,  then  these  standards  would  be 
semantically interoperable also with each other. SAREF and SAREF4ENER themselves have also been 
analysed for missing DSF core data elements.  

SAREF and SAREF4ENER were both checked for the coverage of all core data elements. Subsequently, 
the eight remaining standards have been analysed on their alignment with SAREF/SAREF4ENER. The 
conclusion  is  that  a  certain  level  of  alignment  already  exists.  SPINE  and  oneM2M  are  fully  aligned 
with SAREF/SAREF4ENER. Four standards need further alignment, for which actions are defined. The 
remaining two standards,  CENELEC EN 50491-11 and IEC 61968-9 CIM for Metering, do not have  a 
direct  alignment  with  SAREF/SAREF4ENER,  but  are  aligned  through  the  COSEM  standard,  which 
covers the same interface. 

Digital 
Single 
Market 

 
 
 
 
 
 
 
 
 
 
 
 
 
Table 0-2: Level of alignment 

Standard 

Level of alignment 

EN 50631-1 (SPINE) 

Fully Aligned with SAREF/SAREF4ENER 

oneM2M Base ontology 

Fully Aligned with SAREF 

IEC/CENELEC 62056 COSEM  

Fair alignment with SAREF/SAREF4ENER 

CEN 16836 (ZigBee SEP2) 

Fair alignment with SAREF/SAREF4ENER 

CENELEC EN 50090 (KNX) 

Potential alignment with SAREF/SAREF4ENER 

IEC 61970 CIM 

Potential alignment with SAREF/SAREF4ENER 

CENELEC EN 50491-11 Smart 
Metering 

Aligned with IEC/CENELEC 62056 COSEM 

IEC 61968-9 CIM for Metering 

Aligned with IEC/CENELEC 62056 COSEM 

Alignment 
required 

No 

No 

Yes 

Yes 

Yes 

Yes 

No 

No 

We  further  concluded  that  full  alignment  between  the  selected  standards  and  full  coverage  of  the 
core data elements can be achieved by executing the actions as defined in this study. 

is  needed  and  that 
Overall,  we  conclude  that  alignment  between  standards 
SAREF/SAREF4ENER  can  be  used  as  the  overarching  ontology  to  facilitate  this  alignment.  Several 
actions  and  recommendations  for  various  stakeholders,  such  as  the  Standards  Development 
Organisations, have been identified and are listed in the report. The next step to be taken is to scale 
up the proof of concept that we demonstrated, implementing the resulting SAREF-based solution in 
more use cases for Demand Side Flexibility, in more smart devices and at real consumer sites.  

for  DSF 

Digital 
Single 
Market 

 
 
 
 
 
 
 
 
 
Digital 
Single 
Market 

 
 
 
 
Contents 
Abstract ................................................................................................................................................... 5 

Executive Summary ................................................................................................................................. 7 

Glossary ................................................................................................................................................. 15 

Abbreviations ........................................................................................................................................ 17 

Reading Guide ....................................................................................................................................... 20 

1. 

Introduction ................................................................................................................................... 21 

1.1. 

Policy context ........................................................................................................................ 21 

1.2.  Main objective of this study .................................................................................................. 22 

1.3. 

DSF business process ............................................................................................................. 24 

1.4. 

Scope ..................................................................................................................................... 25 

1.5. 

Approach ............................................................................................................................... 26 

2.  Use Cases and Data Elements ....................................................................................................... 27 

2.1 

2.2 

2.3 

Objective................................................................................................................................ 27 

Approach ............................................................................................................................... 28 

Technical analysis .................................................................................................................. 29 

2.3.1 

Long-list of use cases ..................................................................................................... 29 

2.3.2 

Selection of use cases .................................................................................................... 30 

2.3.3 

Data elements ............................................................................................................... 33 

2.3.4 

Sanity check ................................................................................................................... 34 

2.4 

Results ................................................................................................................................... 37 

3. 

State of Standardisation ................................................................................................................ 41 

3.1 

3.2 

3.3 

Objective................................................................................................................................ 41 

Approach ............................................................................................................................... 41 

Technical analysis .................................................................................................................. 43 

3.3.1 

Long list of standards .................................................................................................... 43 

3.3.2 

Short list of standards ................................................................................................... 47 

3.3.3 

Non-selected standards and industry initiatives ........................................................... 67 

3.4 

Results ................................................................................................................................... 82 

3.4.1 

Short list of standards ................................................................................................... 82 

3.4.2 

Non-selected standards ................................................................................................. 83 

3.4.3 

Positioning of standards ................................................................................................ 85 

3.4.4 

Mapping of use cases, interfaces and standards .......................................................... 85 

4.  Alignments and Actions ................................................................................................................. 88 

Digital 
Single 
Market 

 
 
4.1 

4.2 

4.3 

Objective................................................................................................................................ 88 

Approach ............................................................................................................................... 88 

Technical analysis .................................................................................................................. 90 

4.3.1 

Alignment and Actions for CEN EN 16836 (ZigBee SEP2) .............................................. 90 

4.3.2 

Alignment and Actions for IEC 62056 COSEM ............................................................... 94 

4.3.3 

Alignment and Actions for IEC 61968-9 CIM for metering ............................................ 99 

4.3.4 

Alignment and Actions for IEC 61970 CIM .................................................................. 101 

4.3.5 

Alignment and Actions for CENELEC EN 50491-11 Smart Metering ........................... 104 

4.3.6 

Alignment and Actions for CENELEC EN 50631-1 (SPINE) ........................................... 105 

4.3.7 

Alignment and Actions for CENELEC EN 50090 (KNX) ................................................. 106 

4.3.8 

Alignment and Actions for oneM2M Base Ontology ................................................... 109 

4.4 

Results ................................................................................................................................. 114 

5.  Conclusions and recommendations ............................................................................................ 118 

References ........................................................................................................................................... 120 

Appendix A - Longlist of Use Cases ...................................................................................................... 121 

Appendix B - Workshop on interim results ......................................................................................... 129 

Appendix C - Detailed description of the demonstrations .................................................................. 132 

Digital 
Single 
Market 

 
 
 
Glossary  

Advanced metering 
infrastructure 

Aggregator 

Core data elements 

Demand response 

An  architecture  for  automated,  two-way  communication  between  a 
smart utility meter with an IP address and a utility company.  The goal of 
an AMI is to provides utility companies with real-time data about power 
consumption  and  allow  customers  to  make  informed  choices  about 
energy usage based on the price at the time of use. 

A  market  participant  that  combines  multiple  customer 
loads  or 
generated  electricity  for  sale,  for  purchase  or  auction  in  any  organised 
energy market 

Core  data  elements  are  defined  in  this  study  as  recurring,  common 
concepts  in  the  DSF  domain  that  define  the  meaning  (or  semantics)  of 
the data exchanged between standards. 

The  change  of  electricity  load  by  final  customers  from  their  normal  or 
current  consumption  patterns  in  response  to  market  signals,  including 
time-variable  electricity  prices  or  incentive  payments,  or  in response  to 
acceptance of the final customer's bid, alone or through aggregation, to 
sell  demand  reduction  or  increase  at  a  price  in  organised  markets  as 
defined in Commission Implementing Regulation (EU) No 1348/20141 

Demand side flexibility 

The  ability  to  change  electricity  output  or  demand  in  reaction  to  an 
external signal. 

Device [4] 

Distribution system 
operator 

This study adopts the definition given in [4] according to which a device 
in 
is  a  tangible  object  designed  to  accomplish  a  particular  task 
households,  common public buildings  or offices. In  order to accomplish 
this  task,  the  device  performs  one  or  more  functions.  Examples  of 
devices are a light switch, a temperature sensor, an energy meter and a 
washing machine. A washing machine is designed to wash (task) and to 
accomplish this task it performs a start and stop function. 

A  natural  or  legal  person  responsible  for  operating,  ensuring  the 
maintenance of and, if necessary, developing the distribution system in a 
given  area  and,  where  applicable,  its  interconnections  with  other 
systems  and  for  ensuring  the  long-term  ability  of  the  system  to  meet 
reasonable demands for the distribution of electricity or gas. 

Energy service company 

A  commercial  or  non-profit business  providing  a  broad  range  of  energy 
solutions  including  designs  and  implementation  of  energy  savings 
infrastructure 
projects, 

retrofitting,  energy  conservation,  energy 

1 Commission Implementing Regulation (EU) No 1348/2014 of 17 December 2014 on data reporting 
implementing Article 8(2) and Article 8(6) of Regulation (EU) No 1227/2011 of the European Parliament and the 
Council on wholesale energy market integrity and transparency (OJ L 363, 18.12.2014, p. 121). 

 
 
 
                                                            
Explicit demand side 
flexibility [1] 

outsourcing, power generation and energy supply, and risk management. 

Committed,  dispatchable  flexibility  that  can  be  traded  (like  generation 
flexibility) on the different energy markets (wholesale, balancing, system 
support and reserves markets). This is usually facilitated and managed by 
an aggregator that can be an independent service provider or a supplier. 
This form of DSF is often referred to as “incentive driven” DSF.  

Home Energy 
Management System 

A  technology  platform  comprised  of  both  hardware  and  software  that 
allows the user to monitor energy usage and production and to manually 
control and/or automate the use of energy within a household. 

Implicit demand side 
flexibility [1] 

Consumer’s  reaction  to  price  signals.  Where  consumers  have  the 
possibility  to  choose  hourly  or  shorter-term  market  pricing,  reflecting 
variability  on  the  market  and  the  network,  they  can  adapt  their 
behaviour  (through  automation  or  personal  choices)  to  save  on  energy 
expenses. This type of DSF is often referred to as “price-based” DSF. 

Ontology [4] 

Formal specification of a conceptualization, used to explicit capture the 
semantics of a certain reality 

Smart appliance [4] 

Transmission system 
operator 

This  study  adopts  the  definition  given  in  [4]  according  to  which  smart 
appliances  are  devices,  which  are  used  in  the  household,  e.g.  for 
performing  domestic  work,  and  which  have  the  ability  to  communicate 
with  each  other  and  which  can  be  controlled  via  Internet.  NOTE:  The 
following  appliances  are  covered:  Home  and  buildings  sensors 
(temperature,  humidity,  energy-plugs,  energy  clams,  energy  meters, 
water-flow,  water  quality,  presence,  occupancy,  air  monitors, 
environmental  sensors,  CO2  sensors,  weather  stations,  etc.)  and 
actuators (windows, doors, stores); white goods, as classified by CECED; 
HVAC  (heating,  ventilation,  and  air  conditioning),  classified  by  Eu.bac; 
lighting,  with  use  cases  as  defined  by  LightingEurope;  micro  renewable 
home solutions (solar panels, solar heaters, wind, etc.). 

A  natural  or  legal  person  responsible  for  operating,  ensuring  the 
maintenance of and, if necessary, developing the transmission system in 
a  given  area  and,  where  applicable,  its  interconnections  with  other 
systems,  and  for  ensuring  the  long-term  ability  of  the  system  to  meet 
reasonable demands for the transmission of electricity. 

Digital 
Single 
Market 

 
 
Abbreviations 

AAL 

ADR 

AE 

AMI 

AMR 

CD 

CEM 

CEN 

Ambient Assisted Living 

Automated Demand Response  

Application Entity 

Advanced Metering Infrastructure 

Automated Meter Reading  

Committee Draft for IEC standards 

Customer Energy Manager 

Comité Européen de Normalisation 

CENELEC 

Comité Européen de Normalisation Electro technique 

CIM 

Common Information Model 

CLC TC 

CEN-CENELEC (CLC) Technical Commission (TC) 

COaP 

Constraint Application Protocol 

COSEM 

Companion Specification for Energy Metering 

CSE 

Common Services Entity 

DLMS 

Device Language Message Specification  

DNV-GL 

Det Norske Veritas – Germanischer Lloyd 

DMS 

DHW 

DR 

DSF 

DSO 

E@h 

Distribution Management Systems 

Domestic Hot Water 

Demand Response 

Demand Side Flexibility 

Distribution System Operator 

Energy@home association 

EEBUS 

EEBUS Initiative 

EFI 

EHS 

Energy Flexibility Interface 

European Home System 

 
 
 
 
EIB 

EMG 

EMS 

EN 

European Installation Bus  

Energy Management Gateway 

Energy Management Systems 

European Norm 

ESCO 

Energy Service Company 

ESMIG 

European Smart Metering Industry Group  

ETSI 

H/B/I 

HES 

European Telecommunications Standards Institute 

Home/Building/Industrial 

Head End System 

HEMS 

Home Energy Management System 

HTTP 

HVAC 

IEC 

IoT 

ISO 

KNX  

LNAP 

MDM 

MOU 

MS 

Hyper Text Transfer Protocol 

Heating, ventilation and air conditioning 

International Electrotechnical Commission 

Internet of Things 

International Organization for Standardisation 

KNX association 

Local Network Access Point 

Meter Data Management 

Memorandum Of Understanding 

Metering System 

M2M 

Machine-to-Machine 

NSE 

Network Services Entity 

NNAP 

Neighbourhood Network Access Point 

NSB 

OBIS 

National Standardization Bodies 

Object Identification System  

oneM2M 

Global standards initiative for Machine to Machine Communications  

OpenADR 

Open Automated Demand Response alliance 

Digital 
Single 
Market 

 
 
OSI 

Open Systems Interconnection 

OWL-DL 

Web Ontology Language – Description Logic 

RDF 

Resource Description Framework 

SAREF 

Smart Appliances REFerence ontology 

SAREF4ENER  SAREF for Energy 

SCADA 

Supervisory Control And Data Acquisition 

SGAM 

Smart Grid Architecture Model 

SHACL 

Shapes Constraint Language 

SHIP 

SmartHome IP  

SmartM2M 

Smart Machine-to-Machine communications 

SPINE 

Smart Premises Interoperable Neutral-Message Exchange 

SD 

SDO 

SMG 

TC 

TNO 

ToU 

TSO 

TTL  

UDI 

UML 

URL 

VEE 

W3C 

XSD 

Smart Device 

Standard Development Organisation 

Smart Meter Gateway 

Technical Committee 

Netherlands Organisation for Applied Scientific Research TNO 

Time of Use 

Transmission System Operator 

Turtle format 

Universal Device Interface 

Unified Modeling Language 

Uniform Resource Locator 

Validating, Editing and Estimating 

World Wide Web Consortium 

XML Schema Definition Language 

Digital 
Single 
Market 

 
 
 
 
 
Reading Guide 
To  meet  the  needs  of  readers  of  all  types,  with  different  backgrounds  and  interests,  this  report  is 
setup in a way that all readers can find the topic of their interest quickly and grasp the essence of this 
study. 

For those readers who are interested in the setup and the basic result of the study we refer to the 
executive summary as it explains all that succinctly and on a non-technical level.  

Readers who want to understand the study beyond the level of the executive summary can basically 
be divided into two groups; 1) the reader who want to understand more about the specific approach 
of  each  task,  how  several  steps  of  the  study  have  been  executed  and  the  results  from  these 
individual steps, and 2) the reader who want to understand each technical detail. 

To  accommodate  both  type  of  readers  we  have  created  a  specific  reporting  structure  for  the 
technical chapters: 

- 
- 
- 

Section 2: Selecting uses cases and data elements in the DSF domain (task 1); 
Section 3: Selecting relevant standards (task 2); 
Section 4: Aligning the standards on the selected data elements (task 3). 

Each technical chapter is structured similarly: 

- 
- 
- 

- 

The first section explains the Objective of the task; 
The second section shows the Approach that has been chosen to execute the task; 
The third section describes the Technical analyses that have been performed and the results 
coming from these analyses; 
The final section shows the Results of the task. 

To the reader who wants to understand the study thoroughly without reading all technical details we 
suggest  to  read  the  Objective,  Approach  and  Results.  To  the  reader  who  is  also  interested  in  all 
technical details we suggest to read the Technical analyses as well. 

For  the  technical  readers,  we  would  like  to  point  out  that  Section  3.3  contains  an  extensive 
description of all standards that have been longlisted (20 standards). 

Tasks 4 and 5 of this study have been reported in the Appendix: 

-  Appendix  B  describes  the  details  of  the  workshop  that  has  been  held  with  many  of  the 

stakeholders to discuss the interim results; 

-  Appendix C shows the detailed results of the demonstrations that have been held as a “Proof 

of Concept” of an integrated DSF infrastructure. 

Finally, Section 5 contains the conclusions from this study. Surely the most important results of this 
study are the actions that have been defined to close the gaps and reach semantic interoperability 
between standards. Next to that, we have defined a set of recommendations to reinforce the actions 
domain.
interoperability 
and 

within 

pave 

road 

DSF 

the 

the 

to 

Digital 
Single 
Market 

 
 
1. Introduction  
1.1.  Policy context 
Demand  Side  Flexibility  (DSF)  indicates  the  flexibility  offered  by  residential-consumers  (i.e.,  the 
“demand  side”)  to  voluntary  change  their  typical  electricity  usage  patterns  in  response  to  market 
signals, such as time-variable electricity prices or incentive payments, or to sell their will to modify 
their demand for electricity at a given point in time in organised energy electricity markets, following 
the acceptance of consumers' bids (on their own or through aggregation).  

Demand  side  flexibility  can  help  to  relieve  the  electricity  system  and  the  transmission  and 
distribution  grid,  preventing  black-outs  and  the  costs  related  to  them.  Moreover,  flexible  demand 
side  has  the  potential  to  reduce  the  total  generation  capacity  needed  in  peak  hours,  avoiding 
investments in increasing transportation and distribution capacity. 

The  benefits  of  DSF  consist  of  structural  and  real-time  congestion  management  (e.g.  to 
accommodate  distributed  generation  and  increased  variability  of  demand);  balancing  of  the 
electricity  system  with  respect  to  the  procurement  of  power  reserves,  by  ensuring  that  demand  is 
equal  to  supply  in  real-time;  and  ancillary  services  contracted  by  transmission  system  operators 
guaranteeing system security. 

Demand side flexibility is a resource that benefits and empowers residential consumers and reduces 
total  system  costs,  facilitates  renewables  integration  and  contributes  to  building  Europe’s  smart 
energy  leadership.  The  ‘Clean  energy  for  all  Europeans’  package,  proposed  by  the  European 
Commission  (EC)  in  November  2016,  suggests  updates  of  several  directives,  such  as  the  Energy 
Efficiency  Directive2,  the  Energy  Performance  of  Buildings  Directive3  and  the  Electricity  Directive4. 
The  package  contains  various  provisions  related  to  consumer  engagement,  demand  side  flexibility, 
new energy market entrants (e.g., aggregators) and interoperability. The Electricity Directive calls for 
“activation  and  full  realisation  of  the  flexibility  potential  that  the  demand  side  can  offer”  and  the 
Market Design initiative suggests an environment where short term markets are fully developed and 
integrated, and flexibility plays a key role in enhancing the market value of renewables. 

Large  scale  implementation  of  DSF  has  not  taken  off  yet,  although  several  countries  are  already 
implementing flexible tariffs and some form of Demand Response. The barriers for implementation 
are  regulatory  (e.g.,  regulated  tariffs  and  market  rules  for  operating  flexibility)  and  technical  (e.g., 
interoperability and security). 

The  implementation  of  demand  side  flexibility  not  only  requires  energy  market  players,  such  as 
Distribution System Operators (DSOs) and Energy Service Companies (ESCOs) to cooperate, but also 
their technical infrastructures that manage demand to be coupled. Interoperability is key especially 
where  the  DSO  infrastructure  provides  information  (e.g.,  smart  meter  data)  that  is  needed  by 
demand side flexibility applications.  

On the side of the consumer premises, an important step in addressing the issue of  fragmentation 
and the need for interoperability in the smart appliances industry was made by the EC (DG-Connect) 

2 http://eur-lex.europa.eu/legal-content/EN/TXT/?qid=1485938766830&uri=CELEX:52016PC0761  
3 http://eur-lex.europa.eu/legal-content/EN/TXT/?qid=1490877208700&uri=CELEX:52016PC0765  
4 http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:52016PC0864R%2801%29  

 
 
                                                            
to 

enable 

in  2013,  by  launching  a  standardisation  initiative  (SMART  2013/0077)  in  collaboration  with  the 
European  Telecommunications  Standards  Institute  (ETSI)  to  create  a  shared  semantic  model  of 
consensus 
domain 
(https://sites.google.com/site/smartappliancesproject).  The  development  of  a  reference  ontology 
was targeted as the main interoperability enabler for smart appliances relevant for energy efficiency. 
This resulted in the definition of the Smart Appliances REFerence ontology (SAREF) [4]. Following the 
momentum  gained  during  the  smart  appliances  study,  SAREF  was  published  in  2015  by  ETSI  as  a 
Technical Specification (TS 103 264 V1.1.1). 

interoperability 

appliances 

smart 

the 

in 

SAREF was created with the intention to interconnect data from different protocols and platforms, 
for instance ZigBee (http://www.zigbee.org), UPnP (now OCF, https://openconnectivity.org/) and Z-
Wave  (http://www.z-wave.com),  enabling  the  communication  between  in-home  devices  that  use 
different protocols and standards. SAREF is not about the actual communication with devices and has 
not been set up to replace existing communication protocols and standards, but it lays the base for 
enabling the translation of information coming from existing (and future) protocols and standards to 
and from all other protocols and standards that are referenced to SAREF.  

The  SAREF  initiative  has  been  welcomed  by  the  Smart  Appliances  and  IoT  industry  that  clearly 
indicated the intention to adopt the SAREF ontology and its related communication framework (i.e., 
oneM2M).  As  confirmed  in  the  European  Commission  GROW  Rolling  Plan  for  ICT  Standardisation 
2016, SAREF is a first ontology standard in the IoT ecosystem, and sets a template and a base for the 
development of similar standards for the other verticals to unlock the full potential of IoT.  

In 2016, ETSI requested a Specialists Task Force (STF) to provide input on the management of SAREF 
and create dedicated extensions for specific domains. To that end, the STF 513 was established and, 
in March 2017, the latest version of SAREF has been published (SAREF 2.0), including an extension for 
the  energy  domain,  called  SAREF4ENER,  with  the  goal  to  interconnect  smart  appliances  from 
different  manufacturers  in  demand  response  use  cases  by  means  of  a  Customer  Energy  Manager 
(CEM) that communicates using SAREF. New extensions of SAREF to the Smart Cities, Smart Industry 
&  Manufacturing,  and 
currently  under  development 
(https://portal.etsi.org/STF/STFs/STFHomePages/STF534),  turning  SAREF  into  the  umbrella  that 
enables better integration of semantic data from and across various vertical domains in the IoT. 

Smart  AgriFood  domains  are 

1.2.  Main objective of this study 
In August 2016, the EC (DG-Connect) has issued a tender for a study on “ensuring interoperability for 
demand side flexibility” (SMART 2016/0082), referred to as DSF study in the rest of this document. A 
consortium consisting of DNV GL, TNO and ESMIG was subsequently invited by the EC to conduct the 
study with the goal to identify gaps in standardisation, recommend on alignments needed to achieve 
DSF interoperability on data level and demonstrate an integrated DSF infrastructure.  

The  purpose  of  the  study  is  to  address  the  lack  of  interoperability  in  the  end-to-end  Demand-side 
Flexibility  flow,  by  identifying  the  need  for  alignment  between  data  standards  in  this  flow  and 
providing a solution for several especially relevant use cases. 

With the results of this study and the demonstration of a possible solution, the relevant stakeholders 
will receive clear recommendations on how to adapt/extend their standards to reach interoperability 

Digital 
Single 
Market 

 
 
at  the  level  of  semantics  and  data  elements,  and  initiate  activities  to  perform  the  necessary 
modifications. 

The  study  focusses  on  data  standards  (at  the  semantic  level)  under  the  assumption  that  if  data 
elements specified by different standards are aligned, the information can seamlessly flow through 
the various interfaces of the DSF flow as shown in Figure 1-1. The existing interfaces in the DSF flow 
can and will be implemented using different communication standards depending on specific choices 
made  at  national  level.  To  address  the  issue  of  the  multiple  and  heterogeneous  data  standards 
existing within the smart home, the SAREF ontology5 , provides a valuable contribution. The goal of 
SAREF  is  to  provide  a  common  language  for  the  communication  with  smart  appliances,  by  aligning 
the  data  definitions  adopted  by  multiple  industries  involved  in  home  automation.  Although  the 
physical  connection  with  smart  appliances  can  differ  depending  on  what  specific  protocol  is 
implemented,  SAREF  can  be  used  to  provide  a  shared  language  at  the  semantic  level  for  common 
concepts  that  are  exchanged  between  different  devices  from  various  manufactures  and 
systems/platforms from multiple vendors that all co-exist in the same home/building environment.  

Building  further  on  the  work  started  with  SAREF  on  smart  appliances  at  the  consumer  premises, 
additional  effort  is  needed  for  achieving  semantic  interoperability  along  the  entire  flexibility  value 
chain, from the Smart Grid to smart appliances and smart meters in the home. The purpose of this 
follow-up study is to come to a possible solution for the problem of the multitude of non-aligned (or 
in  some  cases  non-existing)  standards  on  a  semantic  level  on  the  different  interfaces  between  the 
components  of  the  end-to-end  DSF  flow.  With  the  result  of  this  study,  it  is  expected  that  from  a 
semantic interoperability and standardisation point of view the market for demand side flexibility will 
become  fully  functional  and  the  most  common  and  important  use  cases  will  be  made  technically 
possible. 

Through the demonstration of an implementation of data models made interoperable using SAREF, 
the stakeholders will have a reference implementation of an integrated DSF infrastructure via SAREF, 
and a general approach that can guide them to generate interoperability solutions also for standards 
that are not considered in this study.  

Towards  these  objectives  and  per  the  EC  Tender  requirements,  the  DSF  study  is  structured  in  the 
following tasks: 

Task1: Identify representative use cases for DSF and provide an overview of the most recurrent data 
elements  in  these  use  cases.  The  identified  use  cases  are  used  as  basis  for  the  selection  of  data 
elements for DSF and for the demonstrator in Task 5. 

Task  2:  Identify  (a  long  list  of)  relevant  standards  specified  by  standards  developing  organisations 
(SDOs) and industry alliances active in the DSF infrastructure, and identify alignments needed among 
these standards.  

Task  3:  For  (a  short  list  of)  standards  that  sufficiently  cover  the  various  interfaces  of  the  DSF 
infrastructure and  address  the  use  cases  identified  in  Task 1,  elaborate on  the alignments  that  are 
needed to enable DSF interoperability. Provide recommendations to the stakeholders concerned of 

5 https://sites.google.com/site/smartappliancesproject 

Digital 
Single 
Market 

 
 
                                                            
implementing these alignments. Some alignments are implemented by the study itself in Task 5, as 
an example for the stakeholders.   

Task  4:  Organize  a  workshop with relevant  stakeholders  to  present the intermediate  results  of  the 
study and receive their feedback.  

Task  5:  Organize  a  demonstrator  (proof  of  principle)  of  a  possible  solution  for  DSF  interoperability 
based  on  1)  the  use  cases  selected  in  Task  1,  and  2)  the  short-listed  standards  selected  in  Task  3, 
showing how the corresponding misalignments have been solved for the considered use cases and 
standards 

1.3.  DSF business process 
Figure  1-1  provides  a  functional  representation  of  the  DSF  communications  architecture.  Energy 
services can be provided by any party6 (suppliers, balance responsible parties, aggregators or energy 
service  companies)  using  typically  a  public  channel  (such  as  the  internet)  to  access  consumer 
premises. Metering services are most commonly provided by the distribution system operator (DSO) 
that  also  operates  the  advanced  metering  infrastructure  (AMI)  using  a  dedicated  channel  to 
consumer  premises  (regulated  channel).  This  channel  is  used  by  one  party  and  includes  the  smart 
meter. In some countries (such as the UK) the  two channels are combined in one physical channel 
that is operated by a neutral Data Communication Company. 

The  consumer  energy  management  system  controls  and  monitors  the  smart  appliances  and 
communicates with the suppliers of the energy services. 

Figure 1-1 Overview of DSF interfaces 

Consumers can offer flexibility with smart appliances such as heat pumps, smart refrigerators, smart 
washing  machines  or  electric  cars.  The  Consumer  Energy  Management  (CEM)  system,  that  can  be 
located within the consumer premises or in a “cloud application”, controls the smart appliances by 
harmonising all the information from the smart appliances, the requests for flexibility from the grid 
operators or Energy Service Companies, and the comfort level set by the consumer. 

6 One or more commercial companies offering an energy related service to consumers, also referred to as Energy 
Service Company (ESCO). 

Digital 
Single 
Market 

 
 
 
                                                            
The  activities  of  the  consumer  in  the  DSF  process  are,  for  example,  to  enable  a  smart  washing 
machine  for  flexibility  control,  increase  or  decrease  the  in-home  temperature,  and  set  the  electric 
vehicle to be fully loaded at a specific time. In case of unbalances in the network, the grid operator 
can  request  for  flexibility  on  the  market  place  or  directly  intervene  in  the  normal  operation  by 
sending an ‘Emergency signal’ via the AMI. 

What  happens  in  the  DSF  infrastructure  in  case  of  one  of  these  triggers?  Suppose  the  consumer 
enables the washing machine to start washing in the afternoon, with the constraint that it needs to 
be  finished  not  later  than  the  day  after  morning  at  10.  The  smart  washing  machine  sends  this 
information to the CEM including the forecasted demand-profile applicable to the washing-program 
selected  by  the  consumer.  The  CEM  also  receives  the  time-of-use  tariff  profile  from  the  Energy 
Service  Company.  From  this  information,  the  CEM  derives  the  optimal  starting-time  of  the  smart 
washing machine to reduce consumer energy cost as much as possible and sends a start command to 
the appliance.  

When  at  a  certain  moment,  a  DSO  experiences  generation  shortage  or  network  overload  and 
requires  flexibility  in  the  next  few  hours,  they  can  request  for  flexibility  at  the  Energy  Service 
Company,  who  can  send  a  decrease  consumption  request  to  the  CEM,  or  set  a  power  limit  in  the 
smart meter which is forwarded to the CEM via the AMI. 

1.4.  Scope 
The scope of the study is residential consumers because we focus on smart appliances and the use of 
SAREF  for  DSF.  The  SAREF  study  also  studied  residential  consumers  instead  of  industrial  or 
commercial consumers. The use of storage in residential homes is out of scope for this study, as use 
cases and data definitions are being developed and therefore are considered not mature yet. 

The study covers the data standards for the interfaces between applications shown in Figure 1-1. The 
upper  horizontal  channel  is  mainly  used  for  commercial  consumer-focused  energy  services  and 
operations (including demand response). Regulated smart grid communications/operations typically 
use  the  metering  channel,  shown  in  the  lower  half  of  the  diagram.  In  most  Member  States,  the 
metering channel is operated by the Distribution System Operator. This channel is excluded from this 
study,  because  the  data  standards  in  this  domain  have  been  developed  and  aligned  by  the  utility 
industry for electricity meters (CENELEC TC13) and Gas/Water/Heat Meters (CEN TC294). 

A  relevant  interface  is  the  connection  between  the  metering  infrastructure  (AMI,  lower  horizontal 
part  in  Figure  1-1) and the commercial  infrastructure  (upper  horizontal  part  in  Figure  1-1)  because 
this interface connects the regulated domain with commercial applications. Commercial applications 
need to have an open, standards based connection, so that end users can acquire these applications 
anytime and anywhere after the implementation of the AMI. 

The use cases and data standards considered in this study cover all kind of DSF applications and the 
use of flexibility from smart appliances, heating/cooling devices, lighting and EV charging. 

1.5.  Approach  
To reach the objectives as described in Section 1.2, the DSF study is structured in the following way. 

The first step was to create insight in the exchange of data needed for the operation of DSF using the 
interfaces shown in Figure 1-1. This was done by making an inventory of use cases that focus on data 

Digital 
Single 
Market 

 
 
exchange for DSF. The objective was to assure focus on the right data elements for DSF throughout 
the study. Various Technical Committees of SDOs have identified use cases to be used as input for 
defining data communication standards. Since the objective of this study is to reach interoperability 
using official and international standards, the first step focused  on use cases specified by  technical 
SDO Documents for DSF and their related data elements. 

The second  step was  to  identify  existing data  Standards  developed by  SDOs  for  implementation  of 
DSF  to  provide  the  current  state  of  standardisation  for  DSF.  There  are  several  data  standards 
developed by various organisations in both the utility and the IoT sectors. The Invitation to Tender of 
the  EC  already  listed  SAREF  and  oneM2M  among  the  standards  to  be  considered.  Criteria  used  to 
further  populate  the  list  of  relevant  standards  includes  whether  candidate  standards  are  official 
standards specified by SDOs (such as CEN, CENELEC, ETSI, IEC, etc.) or industry alliances active in the 
DSF  infrastructure  (such  as  EEBUS,  Energy@Home,  OpenADR,  etc.),  but  most  importantly  whether 
these standards are widely adopted in practice by the industry. The identification of standards was 
used to assess whether the identified standards cover the main data elements associated to the use 
cases selected in step one.  

The  third  step  was  to  identify  and  elaborate  on  the  data  elements  alignments  needed  among 
standards in the short list.  The underlying idea is that these standards can become interoperable if 
the data elements that they contain are aligned. 

When  alignment  needs  are  discovered,  actions  are  recommended  to  solve  the  misalignments.  The 
SAREF ontology plays an important role in these alignments, as it can be used as a tool to link data 
elements originating from different standards in the DSF landscape. 

Through  a  workshop,  relevant  stakeholders  were  informed  about  the  study  and  its  status.  The 
objective  of  the  workshop  was  to  check  whether  all  relevant  use  cases  and  standards  for  DSF  are 
covered. 

Finally,  solutions  providers  from  the  telecom,  utility  and  smart  appliances  industries  demonstrated 
the implementation of a few use cases and its related data alignments at the European Utility Week 
conference  and  exhibition,  October  2017  in  Amsterdam.  This  demonstration  served  as  a  “Proof  of 
Concept”  of  an  integrated  DSF  infrastructure  and  the  use  of  SAREF  as  enabler  of  interoperability 
among standards specified by different standards organisations.  

Digital 
Single 
Market 

 
 
 
2. Use Cases and Data Elements 
2.1  Objective 
This  section  presents  the  results  of  the  identification  of  use  cases  and  data  elements  task,  whose 
objective  is  to  identify  a  set  of  existing,  relevant  use  cases  for  DSF  and  their  associated  data 
elements. The resulting set of data elements is used to assess whether the standards identified in the 
subsequent  task  (i.e.,  state  of  standardisation  for  DSF  analysis),  sufficiently  cover  the  use  cases  of 
interest  for  this  study.  The  use  cases  and  associated  data  elements  have  been  identified  from 
technical reports developed by SDOs.  

Figure 2-1: DSF architecture and its interfaces 

Figure  2-1  provides  a  technical  representation  of  the  high-level  DSF  data  flow  previously  shown  in 
Figure 1-1. This technical representation shows:  

- 

- 

the upper channel, which consists of the systems and interfaces of the commercial 
domain  from  Actor  A  (i.e.,  the  Energy  Services  Company)  to  the  smart  appliances, 
located in the home; and  
the  lower  channel,  which  consists  of  the  systems  and  interfaces  of  the  regulated 
domain from Actor B (i.e., the Metering Services Company) to the smart meter. 

In  the  lower  channel  (in  the  regulated  domain)  typical  systems  and  devices  used  are:  Meter  Data 
Management  (MDM),  Head  End  System  (HES)  that  collects  the  meter  data  on  regular  intervals, 
Neighbourhood  Network  Access  point  (NNAP)  that  collects  data  on  neighbourhood  level  (also 
referred  to  as  Data  Concentrator),  Smart  Meter  Gateway  (or  Local  network  Access  Point)  and  the 
Smart Meter. The Consumer Energy Management system (CEM) monitors and controls local Demand 
Side  Flexibility  by  having  a  direct  interface  with  smart  appliances,  local  storage  and  generation 
sources.  

Please note that this architecture is functional: functions can be combined in one device and some 
functions (such as NNAP, LNAP) are optional. 

This  study  focuses  on  interfaces  G3,  S1,  S2,  H1  and  H2.  The  interfaces  G3,  S1  and  S2  are  in  the 
commercial domain where several different standards exist that need to become interoperable for 
the information to flow seamlessly through the end-to-end DSF data flow. The H2 and H1 interfaces 

Digital 
Single 
Market 

 
 
 
are in scope as they interact with the commercial domain; directly in case of the H2 interface, and 
indirectly (via the consumer) in case of the H1 interface. These H interfaces are important because 
they  connect  the  metering 
in  the  regulated  domain  with  the  commercial 
infrastructure.  

infrastructure 

The G3 interface represents a Wide Area Network that is used by Actor A (Energy Services Company) 
to  connect  to  the  consumer.  Often,  this  is  the  Internet.  Standards  positioned  in  this  interface  are 
usually developed by the telecom industry. 

The  H1  interface  provides  a  connection  to  the  smart  meter,  in  most  cases  used  to  connect  an  In-
Home-Display (IHD) for consumers to get consumption data. H2 is an important interface connecting 
the  AMI  (smart  grid  component)  with  commercial  applications.  Interoperability  on  this  interface  is 
therefore key for the market development of DSF applications. The standards for these interfaces are 
originating from both the utility and Home Automation industries. 

The  CEM  interfaces  S1  and  S2  are  developed  and  standardized  by  the  Home  Automation  industry 
specifically. 

2.2  Approach 
European  standardisation  organisations  and  international  standard  development  organisations  are 
continuously working on so called ‘technical reports’ in which use cases, and technical requirements 
are  being  described.  Relevant  standardisation  organisations  in  the  scope  of  this  study  are  Comité 
Européen de  Normalisation  (CEN),  Comité Européen  de Normalisation  Electro  technique (CENELEC) 
and  European  Telecommunications  Standards 
international  standard 
development  organisation  that  fits  the  scope  of  this  study  is  the  International  Electrotechnical 
Commission  (IEC).  IEC  and  CENELEC  are  working  together  to  facilitate  a  consensus-finding  process 
between European and international standards development activities in the electrical sector. 

(ETSI).  The 

Institute 

These standardisation organisations have collected existing use cases and/or developed use cases for 
evaluating  or  defining  their  communication  standards.  Their  technical  reports  can  therefore  be 
considered  as  a  fair  representation  of  the  existing  use  cases  for  this  study.  The  first  step  in  the 
approach was to put together a long list of use cases from the technical reports from the mentioned 
standardisation organisations. 

The second step was to create a short list of use cases that can be used as representative to further 
proceed with the study. The short list has been selected based on the following criteria: 

1.  The data exchange resulting from the use case should not cover a single interface, but multiple 
interfaces in Figure 2-1. This criterion makes sure that the use cases are relevant for the mapping 
of data elements from different standards via the SAREF ontology (i.e., if only one interface was 
involved, there would not be an interoperability issue, as only one standard could be used for the 
data  exchange).  Note  that  this  criterion  can  also  be  satisfied  by  grouping  use  cases  that 
individually involve one interface, into a more complex use case that involves the combination of 
individual interfaces. 

2.  The description of the use case should be detailed enough to identify data elements. If the use 
case description is too general, the data elements cannot be identified and thus it is not possible 

Digital 
Single 
Market 

 
 
to  link  the  use  cases  to  the  data  standards  for  DSF  considered  in  the  state  of  standardization 
analysis of task 2. 

3.  The use case should involve smart appliances in consumer homes.  

The third step was to identify the data elements that are exchanged through the interfaces in Figure 
2-1 for the short-listed use cases.  

Finally, a sanity check has been performed to secure that the selected use cases sufficiently cover the 
field  of  DSF.  The  sanity  check  is  done  leveraging  the  extensive  knowledge  of  the  study  team 
regarding  the  work  of  the  Universal  Smart  Energy  Framework  (USEF)  foundation,  which  has 
described  the  interaction  between  energy  companies  (Actor  A  in  Figure  2-1),  consumers  and  smart 
appliances. The use cases should cover all major functionalities described by USEF. 

2.3  Technical analysis 
2.3.1  Long-list of use cases 
The  first  step  in  composing  a  long  list  of  uses  cases  is  to  identify  officially  and  internationally 
recognized use cases regarding the DSF flow. As mentioned in the approach CEN, CENELEC, ETSI and 
IEC  are  recognized  as  official  organisations  that  have  been  active  in  the  field  of  DSF,  working  on 
technical  reports  in  which  use  cases  have  been  described,  relevant  to  the  scope  of  this  study.  The 
technical reports that are considered relevant for this study are:  

- 

- 

IEC/TR 62746-2:2015; Systems interface between customer energy management system and 
the power management system – Part 2: Use cases and requirements; 
IEC/TS  62913-2-3  ED1;  Generic  Smart  Grid  Requirements  -  Part  2-3:  Domains  -  Resources 
connected  to  the  grid  related  domains,  these  include  Bulk  Generation,  Distributed  Energy 
Resources, Smart Home / Commercial / Industrial /  DR-Customer Energy Management,  and 
Energy Storage; 

-  prEN  50631-1;  Household  appliances  network  and  grid  connectivity  -  Part  1:  General 

Requirements, Generic Data Modelling and Neutral Messages; 
ETSI TR 103 411 V1.1.1; Smart M2M; Smart Appliances, SAREF extension investigation. 

- 

These  technical  reports  have  a  broader  scope  than  just  DSF,  such  as  “metering”  or  “energy 
management”. The focus has been on the parts of these data standards that can be used for DSF.  

Assessment technical reports 

DNV  GL  has  assessed  these  technical  reports  on  the  described  use  cases  applicable  for  the  DSF 
domain and its associated data elements. The following observations have been made: 

IEC/TR 62746-2:2015  The  document  contains  a  large  set  of  use  cases  that  in  most  cases  involve 
Smart  Devices  in  the  consumer  home.  The  level  of  detail  and  the  use  of 
sequence diagrams, make this document very useful for this study. The data 
elements used on several interfaces can be derived in a straightforward way 
from the sequence diagrams. 

IEC/TS 

62913-2-3  The  use  cases  are  described  generic  and  data  elements  are  not  explicitly 
mentioned like in IEC/TR 62746-2:2015. In section A.2 it is shown that all use 

Digital 
Single 
Market 

 
 
ED1 

prEN 50631-1 

cases  from  the  DSF  domain  are  linked  to  one  or  multiple  use  cases  in 
document  IEC/TR  62746-2:2015,  meaning  that  this  document  does  not 
provide  new  uses  cases  in  addition  to  the  ones  found  in  IEC/TR  62746-
2:2015. 

All  use  cases  in  this  document  refer  to  the  use  cases  from  IEC/TR  62746-
2:2015 (see section 5.1 of prEN 50631-1), meaning that this document does 
not provide new uses cases in addition to the ones found in IEC/TR 62746-
2:2015. 

ETSI  TR  103  411 
V1.1.1 

The  use  cases  in  this  document  were  based  on  the  use  cases  from  IEC/TR 
62746-2:2015  (see text  on page  14  of  the  technical report),  except for  use 
case 1 (Device Registration & Configuration) which is not present in IEC/TR 
62746-2:2015. 

Based on these observations it can be concluded that technical report IEC/TR 62746-2:2015 should 
be considered as the main contributor of use cases and associated data elements. 

The long list of use cases selected for this study is composed by collecting use cases from each of the 
four  technical  reports.  The  long  list  is  presented  in  Appendix  A,  where  for  each  technical  report  a 
table is included with the reference to the use case description used in the technical report.  

2.3.2  Selection of use cases  
Short-listing  the identified  use  cases  from the long  list  has  resulted in a  selection  of  ten use  cases. 
The use cases have been selected based on the criteria as mentioned in the approach (section 2.2).  
Appendix  A  elaborates  in  more  detail  on  the  rationale  behind  the  selection  process.  Table  2-2 
presents the short-listed use cases. 

Table 2-2: Selected use cases 

# 

1 

2 

3 

Name 

Description 

Device Registration 
& Configuration 

Before  a  smart  device  can  be  used  in  DSF,  it  needs  to  be  incorporated  in  the 
system. 

The new smart device must become visible to the CEM to be added to the list of 
products to manage. During the registration process, the new smart device must 
provide its ID and capabilities to CEM so that it can be properly configured. 

Actor  A  may  also  use  this  use  case  to  register  all  local  CEMs,  as  they  need  to 
register flexibility potential of all their customers. 

start  of 

Flexible 
Smart Device 

In some cases, smart devices provide flexibility towards their operation time. The 
device can manage its flexible running times by itself and communicates them to 
the  CEM.  Flexible  running  times  also  depend  on  ‘profiles’  selected  by  the 
consumer. 

Optimal  time  slots  for  operation  can  be  recalculated  because  of  external 
information, like price information received by the CEM from the Energy Supplier. 

Response  of  Smart 
to 
Home 

The grid is close to a black-out and will soon have to cut off sections of the grid. As 
a means of preventing this by limiting the overall energy consumption to a certain 

Digital 
Single 
Market 

 
 
# 

Name 

Description 

4 

5 

6 

7 

8 

9 

Emergency 

minimum, the grid sends an emergency message to all connected CEMs. The CEM 
informs the Smart Devices. A notification is provided to the consumer. 

Control  of  non-
smart  Device  by 
CEM,  based  on 
tariff 
pre-set 
threshold  (set  by 
user)  and  actual 
tariff 

This use case deals with the control of a domestic heat pump or other non-smart 
controller  by  a  CEM  system  based  upon  real  time  tariff  (price)  information 
received from the Energy Supplier. The EMS requests the controller to either turn 
on/increase  operation  power  or  turn  off/decrease  operating  power  depending 
upon  both  real  time  price  information  received  from  the  Energy  supplier  and  a 
price threshold set by the consumer. By doing so, a ‘non-smart’ device is operated 
smart. 

Direct Load Control 
of Smart Device via 
CEM 

Demand  Side  Management  messages  are  sent  to  the  CEM  to  trigger  a  program 
that manages load by interacting with several in home smart devices connected to 
the CEM. 

by 

Demand-supply 
adjustment 
cooperation 
between 
and customer  

supplier 

This  use  case  is  intended  to  achieve  lower  total  energy  cost  by  means  of 
cooperation  between  more  than  one  consumer  and  an  energy  supplier.  Every 
consumer makes a profile of energy consumption regarding initial information on 
prices from the energy supplier. The energy supplier aggregates a profile of energy 
consumption.  

Exchanging 
information 
(partial) 
consumption 

on 

The Smart Devices send consumption information to the CEM. The CEM sends the 
information  to  the  energy  Supplier.  Consumption  information  can  be  partial 
consumption  or  total  consumption.  Consumption  information  can  be  actual  or 
forecasted  consumption.  Actual  consumption  can  also  be  send  by  the  Smart 
Meter. 

External 
Actor 
Retrieves  status  of 
smart devices 

This use case describes how an external actor retrieves the state of a smart device 
directly from the CEM. In case of a remote controllable smart device is connected 
to  the  CEM,  the  CEM  asks  status  information  to  individual  remote  controllable 
devices. The status information gives e.g. insight in the available flexibility. 

CEM requests time 
from  Smart  Meter 
Smart 
GW 
and 
Meter 
GW 
synchronizes  time 
of CEM 

Since  the  CEM  can  manage  local  consumption  /  generation  based  on  flexible 
tariffs while the billing will take place on information in the smart meter, both the 
smart  meter  and  the  CEM  need  to  have  the  same  tariff  schedule  and  need  to 
know  when  a  new  tariff  applies.  This  can  be  achieved  by  time  synchronisation 
between the CEM and the smart meter.  

10 

Smart  Meter  GW 
actual 
notifies 
tariff to CEM 

Since  the  CEM  can  manage  local  consumption  /  generation  based  on  flexible 
tariffs while the billing will take place on information in the smart meter, both the 
smart  meter  and  the  CEM  need  to  have  the  same  tariff  schedule  and  need  to 
know when a new tariff applies. This can be achieved by tariff change notification 
by the smart meter towards the CEM. 

Several of the short-listed use cases have been assembled from multiple use cases. As described in 
the approach, one use case may not comply with the criteria, however, when grouped with other use 
cases, together they can form a use case that does comply with the criteria. 

Digital 
Single 
Market 

 
 
 
Use case 2 is an example of a grouped use case. As you can see in Appendix A, the first five use cases 
from  technical  report  IEC/TR  62746  do  not  all  cover  multiple  interfaces  (criterion  1),  however 
combined  into  one  use  case,  a  quite  sophisticated  use  case  appears  that  does  cover  multiple 
interfaces.  

The five use cases from technical report IEC/TR 62746 are: 

- 
Flexible start of a Smart Device 
- 
Smart Device informs CEM about flexible start 
-  CEM informs Smart Device about starting time 
-  CEM informs SD about slot shift 
-  Control of Smart appliances based on price information by time slot 

These individual use cases have been grouped into Flexible Start of Smart Device. The data elements 
corresponding  with  the  five  individual  use  cases  are  all  integrated  in  the  grouped  use  case,  thus 
creating one general but at the same time detailed use case, covering all aspects of, in this specific 
case, the flexible start of smart devices. 

In the same way use cases 3, 4, 7 and 8 have been grouped as well. We refer to Appendix A for more 
details. 

Recommendation 

During the analysis, we found  a use case regarding Power Limitation to be missing in the technical 
reports. Therefore, we recommend the following: 

A  common  smart  meter  use  case  is Power  Limitation,  in which  a  power  limit  is  set  into  the 
smart meter via Actor B (the DSO). The CEM can use this power limit, together with the actual 
power consumption of smart devices, to control the power consumption of individual smart 
devices. However, the technical reports selected for this study do not mention this specific use 
case. It is recommended that this use case is being developed with the data elements power 
limit and actual power consumption. 

2.3.3  Data elements  
From  the  short-listed  use  cases,  the  data  elements  that  are  associated  with  these  use  cases  have 
been identified and are presented in Table 2-3, positioning them with respect to the corresponding 
interfaces (G3, S1, S2, H1 and H2) from Figure 2-1. 

The data elements are derived from the use cases descriptions provided in the technical reports. For 
use cases that are only described in one technical report, that description is used as source to extract 
the associated data elements. For use cases described in more than one document, the description 
from  IEC/TR  62746-2:2015  is  used,  as  this  technical  report  explicitly  provides  definitions  of  data 
elements associated to its use cases. 

Digital 
Single 
Market 

 
 
 Table 2-3: Selected use cases and involved interfaces and data-elements 

Identified data elements 

-  Device Identifier 
-  Device capabilities 

Control parameters, e.g. profile selection 
Preferred time slot of operation per Device 
Flex start enabled  
Energy consumption  
Energy Profile 
Start time/ time slot of operation 

- 
- 
- 
- 
- 
- 
-  New tariff information 
- 
-  Operation commands 
- 
Emergency signal 
- 
Emergency load command 

Recalculated start time / time slot  

Tariff threshold 
Real Time Tariff 
operation commands (increase or decrease power 
and turn off/on) 

Id of participating devices 
Power thresholds 
Load management signal 
Load adjustment command 
Feedback about adjustment 
Expected change in consumption 
Price information of electrical energy based on time 
of use (TOU) 
Planned load profile (expected consumption in time) 

- 
- 
- 

- 
- 
- 
- 
- 
- 
- 

- 

- 

Actual Individual Appliances (= partial) 
consumption/generation 
Forecasted partial consumption/generation 
Actual total house consumption 
Forecasted total house consumption 

- 
- 
- 
-  Device Status Request 
-  Device Status 
- 

Status is displayed to consumer 

# 

1 

2 

3 

4 

5 

6 

7 

8 

9 

Use case 

Device Registration & 
Configuration 

Involved 
interfaces 

S1, S2, G3 

Flexible start of Smart 
Device 

G3, S1, S2, 
H2 

Response of Smart 
Home to Emergency 

S1, S2, H2 

G3, S1, S2 

Control of non-smart 
Device by CEM, based 
on pre-set tariff 
threshold (set by user) 
and actual tariff 

Direct Load Control of 
Smart Device via CEM 

G3, S1, S2 

G3, S1, S2 

Demand-supply 
adjustment by 
cooperation between 
supplier and customer 

Exchanging 
information on 
(partial) consumption 

G3, S1, S2, 
H2, H1 

G3, S1, S2 

External Actor 
Retrieves status of 
smart devices 

CEM requests time 
from Smart Meter GW 
and Smart Meter GW 
synchronizes time of 
CEM 

S1, H2 

- 
- 

Actual time request 
Actual time 

Digital 
Single 
Market 

 
 
 
 
# 

Use case 

10 

Smart Meter GW 
notifies actual tariff to 
CEM 

Involved 
interfaces 

S1, H2 

Identified data elements 

- 

Active tariff notification 

2.3.4  Sanity check 
In  this  section  a  final  assessment,  or  “sanity  check”,  is  performed  to  evaluate  whether  the  short-
listed  use  cases  sufficiently  cover  the  field  of  DSF,  checking  the  risk  that  important  use  cases  are 
missing.  

The sanity check is performed based on the work of the Universal Smart Energy Framework (USEF) 
foundation7.  USEF  is  created  by  and  applicable  in  multiple  Member  States,  its  applicability  is  not 
limited by location or technology. Compared to similar market models USEF describes the interaction 
within the DSF flow comprehensively; the interaction between  a market actor (energy company or 
consumer) and the smart appliances. For these reasons USEF is well suited for performing the sanity 
check. 

According to USEF, actor A (from figure 2.1) can be covered by multiple roles; an energy supplier, an 
aggregator,  a  distribution  operator  (DSO)  or  a  transmission  operator  (TSO).  USEF  identifies  main 
functionalities for each role. The sanity check is performed by checking if: 

- 
- 

all roles that Actor A could assume are covered; 
all main functionalities are covered;  

Main functionality of the supplier: 

- 

Providing  price  signals;  the  information  exchange  between  the  supplier  and  the  home  is 
limited to price signals. Based on these price signals, the consumer can choose to  adapt its 
behaviour (through automation, personal choices or manual interventions) to save on energy 
expenses.  

Main functionalities of the aggregator: 

- 

(De)Commissioning; prior to operation devices need to be configured and registered. When 
taken out of operation, decommissioning is required. The devices need to be known by the 
CEM (interface S2), but also by Actor A (interface G3). 

-  Maintenance; devices may require maintenance, such as software updates. 
-  Monitoring; the aggregator communicates with the devices to understand the flexibility that 
is available and thus can be offered. The aggregator for instance needs to monitor the status 
and consumption of the devices to be able to offer, request and schedule flexibility. 

7 USEF, the framework explained, USEF, Nov 2015; USEF, the framework specifications, USEF, Nov 
2015; Recommended practices and key considerations for a regulatory framework and market design 
on explicit Demand Response, USEF, Nov 2016 

Digital 
Single 
Market 

 
 
 
 
 
                                                            
- 

- 

- 

Scheduled activation; the aggregator needs control elements to be able to dispatch the exact 
amount of energy or power required. The aggregator needs to be able to schedule a device 
to start or stop consuming or producing. 
Instantaneous activation; the aggregator needs control elements to be able to dispatch the 
exact amount of energy or power required. The aggregator needs to be able to immediately 
activate a device to start or stop consuming or producing. 
In-home  optimization:  the  aggregator  can  offer  a  proposition  to  optimize  the  prosumers 
flexibility  profile  to  optimize  its  savings  or  earnings.  Based  on  price  signals  and  status  of 
devices each individual profile can be optimized. 

Main functionality of the operator: 

- 

Instantaneous activation; In exceptional situations where the market is not able to maintain 
the  grid  load  within  acceptable  limits,  the  distribution  operator  temporarily  overrules  the 
market  to  prevent  a  complete  power  outage.  The  DSO  can  differentiate  its  connection 
conditions, thereby providing different levels of reliability to different types of connections. 
These conditions establish connection priorities, enabling the DSO to differentiate between 
clients  who  critically  depend  on  energy  (such  as  nursing  homes)  and  connections  where  a 
service interruption has a lesser impact (such as public charging stations for electric vehicles). 
As soon as the system restores itself, the market can take over again. 

Mapping use cases to functionalities 

In the table below the short-listed use cases are mapped in the main functionalities. 

Table 2-4: Mapping of selected use cases on the actors’ functionalities 

Actor A 

Main functionality 

Use Case 

Supplier 

Provide price signals 

6 - Demand-supply adjustment by cooperation 
between supplier and customer 

10 - Smart Meter GW notifies actual tariff to CEM 

Aggregator 

(De)Commissioning 

1 - Device Registration & configuration 

Maintenance 

No use case mapped 

Monitoring 

7 – Exchanging information within the home 

8 - External Actor Retrieves status 

Scheduled activation 

2 - Flexible start of Smart Device 

9 - CEM requests time from Smart Meter GW 

Instantaneous activation 

5 - Load Control of Smart Device by CEM. 

In-home optimization 

4 - Control of Smart Device by CEM 

DSO / TSO 

Instantaneous activation 

3 - Response of Smart Home to Emergency 

Digital 
Single 
Market 

 
 
 
 
Mapping use cases on supplier functionality 

There are three paths the information on energy price can follow: 

  G3  –  S1  -  S2:  Through  the  deregulated 

infrastructure  to  the  flexibility  resources 

This may trigger an automated response. This is covered by use case 6. 

  G2  –  H2  –  S1  –  S2:  Through  the  smart  meter  gateway  to  the  flexibility  resources 

This may trigger an automated response. This is covered by use case 10. 

  G2  –  H1: 

the 

  Through 

in-home  display 
This may trigger a manual intervention. This is not covered by the use cases, and not taken in 
account  in  the  study,  since  it  concerns  only  one  interface  in  the  scope  of  the  study  and 
therefore alignment is not needed.  

smart  meter  gateway 

the 

to 

It  can  be  concluded  that  the  main  functionality,  providing  the  home  with  tariff  information,  is 
included in the use cases. Two paths can be followed, either through the deregulated infrastructure, 
or through the smart meter infrastructure. 

Mapping use cases on aggregator functionality 

The main functionalities as described can be mapped as follows: 

 

(De)Commissioning 
1 
Use  case  1  describes  the  commissioning  of  a  smart  appliance.  Decommissioning  is  not 
described. 

covered 

case 

use 

by 

is 

  Maintenance 

is 

case 
There  is  no  use  case  mapped  on  the  maintenance  functionality.  We  have  found  that 
maintenance functions are not yet covered by international standards. 

covered 

any 

use 

not 

by 

  Monitoring 

is 

covered 

by 

use 

case 

7 

and 

8 

Use cases 7 and 8 describe all relevant elements of the monitoring process. 

  Scheduled 

is 

by 

use 

covered 

activation 

9 
If  there  is  time  between  the  notification  and  the  activation  of  the  flexibility  within  an 
energy  market  or  product,  the  aggregator  can  apply  a  scheduled  activation.  This  is 
sufficiently  covered  by  use  case  2.  Internal  clocks  need  to  be  synchronized  for  this 
functionality and therefore use case 9 can be mapped here as well. However, use case 9 is 
an  operational  functionality  that  can  also  be  mapped  on  other  functionalities  such  as 
monitoring, and in-home optimization. 

case 

and 

2 

 

 

activation 

Instantaneous 
5 
If  there  is  no  time  between  the  notification  and  the  activation  of  the  flexibility  within  an 
energy market or  product,  the aggregator  must apply  an  instantaneous  activation.  This  is 
sufficiently covered by use case 5. 

covered 

case 

use 

by 

is 

In-home 
4 
Although  the  ESCo  is  the more  logical  role  to  facilitate in-home  optimization  (which  does 

optimization 

covered 

case 

use 

by 

is 

Digital 
Single 
Market 

 
 
not create value for an Aggregator), USEF recognizes that in-home optimization may create 
value for the Prosumer/customer. This is covered by use case 4.  

It can be concluded that the use cases sufficiently cover the monitoring and control activities of the 
aggregator in all relevant markets and products. Decommissioning is not covered.  

Mapping use cases on operator functionality 

The most obvious technology a DSO can apply is the switch in the smart meter, if installed. Also, the 
DSO can temporarily define a threshold on the capacity. When this threshold is exceeded, the switch 
will be triggered. If the HEMS is informed about the level of the threshold, it can ensure (by using the 
available  flexibility) that  the total  consumption does  not  exceed  the  threshold. This  functionality is 
covered by use case 3.  

Since  this  is  limited  to  emergency  situations,  the  functionality  is  also  rather  limited.  This  is  fully 
covered by use case 3. 

Conclusion of the sanity check 

From the analysis, it can be concluded that the short-listed use cases; 

-  Cover all roles that Actor A could assume; 
-  Cover all main functional decompositions that USEF describes;  

2.4  Results 
Ten  use  cases  and  their  associated  data  elements  are  identified  as  relevant  for  further  use  in  the 
project.  These  uses  cases  are  selected  from  the  work  done  by  relevant  Standard  Development 
Organizations  (SDO)  such  as  the  European  Committee  for  Standardization  (CEN),  the  European 
Committee  for  Electrotechnical  Standardization  (CENELEC),  the  European  Telecommunications 
Standards Institute (ETSI) and International Electrotechnical Commission (IEC). 

The  selected  use  cases  are  identified  as  a  good  fit  with  the  scope  of  Demand  Side  Flexibility.  The 
scope  of  the  selected  use  cases  has  been  verified  with  the  scope  of  the  Universal  Smart  Energy 
Framework (USEF). It has been concluded that the scope of the selected use cases fits the relevant 
functionalities described by USEF. 

The selected use cases and its associated data elements are presented in the table below. 

Table 2-5: Selected use cases and the associated data elements 

Use case 

Description 

Data elements 

Device Registration & 
Configuration 

Before a smart device can be used in DSF, it 
needs to be incorporated in the system. 

-  Device Identifier 
-  Device capabilities 

The new smart device must become visible to 
the CEM to be added to the list of products to 
manage. During the registration process, the 
new smart device must provide its ID and 
capabilities to CEM so that it can be properly 
configured. 

Digital 
Single 
Market 

 
 
 
Use case 

Description 

Data elements 

Flexible start of Smart 
Device 

Response of Smart 
Home to Emergency 

Control of non-smart 
Device by CEM, based 
on pre-set tariff 
threshold (set by user) 
and actual tariff 

Direct Load Control of 
Smart Device via CEM 

Actor A may also use this use case to register all 
local CEMs, as they need to register flexibility 
potential of all their customers. 

In some cases, smart devices provide flexibility 
towards their operation time. The device can 
manage its flexible running times by itself and 
communicates them to the CEM. Flexible 
running times also depend on ‘profiles’ 
selected by the consumer. 

Optimal time slots for operation can be 
recalculated because of external information, 
like price information received by the CEM 
from the Energy Supplier. 

The grid is close to a black-out and will soon 
have to cut off sections of the grid. As a means 
of preventing this by limiting the overall energy 
consumption to a certain minimum, the grid 
sends an emergency message to all connected 
CEMS. The CEM informs the Smart Devices. A 
notification is provided to the consumer. 

This use case deals with the control of a 
domestic heat pump or other non-smart 
controller by a CEM system based upon real 
time tariff (price) information received from 
the Energy Supplier. The EMS requests the 
controller to either turn on/increase operation 
power or turn off/decrease operating power 
depending upon both real time price 
information received from the Energy supplier 
and a price threshold set by the consumer. By 
doing so, a ‘non-smart’ device is operated 
smart. 

Demand Side Management messages are sent 
to the CEM to trigger a program that manages 
load by interacting with several in home smart 
devices connected to the CEM. 

Demand-supply 
adjustment by 
cooperation between 

This use case is indented to achieve lower total 
energy cost by means of cooperation between 
more than one consumer and an energy 

Digital 
Single 
Market 

- 

- 

- 
- 
- 
- 

Control parameters, e.g. 
profile selection 
Preferred time slot of 
operation per Device 
Flex start enabled  
Energy consumption  
Energy Profile 
Start time/ time slot of 
operation 

-  New tariff information 
- 

Recalculated start time / time 
slot  

-  Operation commands 

- 
- 

Emergency signal 
Emergency load command 

- 
Tariff threshold 
- 
Real Time Tariff 
-  Operation commands 

(increase or decrease power 
and turn off/on) 

- 
- 
- 
- 
- 
- 

- 

- 

Id of participating devices 
Power thresholds 
Load management signal 
Load adjustment command 
Feedback about adjustment 
Expected change in 
consumption 

Price information of electrical 
energy based on time of use 
(TOU) 
Planned load profile 

 
 
Use case 

Description 

Data elements 

supplier and customer  

Exchanging 
information on 
(partial) consumption 

External Actor 
Retrieves status of 
smart devices 

CEM requests time 
from Smart Meter GW 
and Smart Meter GW 
synchronizes time of 
CEM 

Smart Meter GW 
notifies actual tariff to 
CEM 

supplier. Every consumer makes a profile of 
energy consumption regarding initial 
information on prices from the energy supplier. 
The energy supplier aggregates a profile of 
energy consumption.  

The Smart Devices send consumption 
information to the CEM. The CEM sends the 
information to the energy Supplier. 
Consumption information can be partial 
consumption or total consumption. 
Consumption information can be actual or 
forecasted consumption. Actual consumption 
can also be send by the Smart Meter. 

This use case describes how an external actor 
retrieves the state of a smart device directly 
from the CEM. In case of a remote controllable 
smart device is connected to the CEM, the CEM 
asks status information to individual remote 
controllable devices. The status information 
gives e.g. insight in the available flexibility. 

Since the CEM can manage local consumption / 
generation based on flexible tariffs while the 
billing will take place on information in the 
smart meter, both the smart meter and the 
CEM need to have the same tariff schedule and 
need to know when a new tariff applies. This 
can be achieved by time synchronisation 
between the CEM and the smart meter.  

Since the CEM can manage local consumption / 
generation based on flexible tariffs while the 
billing will take place on information in the 
smart meter, both the smart meter and the 
CEM need to have the same tariff schedule and 
need to know when a new tariff applies. This 
can be achieved by tariff change notification by 
the smart meter towards the CEM. 

(expected consumption in 
time) 

- 

- 

- 

- 

Actual Individual Appliances 
(= partial) 
consumption/generation 
Forecasted partial 
consumption/generation 
Actual total house 
consumption 
Forecasted total house 
consumption 

-  Device Status Request 
-  Device Status 
- 

Status is displayed to 
consumer 

- 
- 

Actual time request 
Actual time 

- 

Active tariff notification 

Digital 
Single 
Market 

 
 
 
 
3. State of Standardisation  
3.1  Objective 
The main problem addressed in the DSF study is that a multitude of data communication standards 
exist in the end-to-end DSF flow, which are not semantically aligned. Therefore, after identifying the 
most relevant use cases and associated data elements, it  was relevant to take stock of the existing 
standards that cover these data elements. 

The underlying assumption was that if the data elements specified by the DSF standards are aligned, 
then  the  information  exchanged  in the  use  cases  under  consideration can  seamlessly  flow  through 
the  different  interfaces  between  smart  appliances,  consumer  energy  management  system,  energy 
management  gateway,  energy  services,  smart  meter  gateway  and  smart  meters  (see  Figure  2-1). 
Therefore,  an important  part  of  our  state of  standardization  analysis  was  to  elaborate  on the  data 
elements defined by different standards, as a basis for further alignment.  

To guarantee that the  standards identified in Section 3  cover the data elements of interest for the 
use  cases  in  this  study,  it  was  assessed  whether  their  data  elements  match  the  data  elements 
identified in the use case analysis in Section 2.  

The main objectives of our state of standardisation analysis can be summarized as follows: 

Identify existing standards developed by SDOs for implementation of DSF; 

- 
-  Assess whether the identified standards cover the main data elements exchanged in the DSF 
flow,  as  described  by  the  use  cases  in  Section  2,  by  using  SAREF  and  SAREF4ENER  as  a 
common mapping tool.  

3.2  Approach  
As a first step, a long list of relevant standards has been identified to clarify which existing standards 
are relevant for DSF, based on the following Long List (LL) criteria:  

  Criterion  LL1:  The  standard  should  be  applicable  for  (residential)  Home  Energy  Management/ 
DSF and cover (one or more of) the interfaces relevant for the study between smart appliances, 
smart  meters,  consumer  energy  management  system,  energy  management  gateway,  smart 
meter gateway, energy services and metering services (see Figure 2-1); 

  Criterion  LL2:  The  standard  should  be  widely  adopted  by  the  industry  and  used  in  practice. 
Preferably, the standard is officially published by SDOs (e.g., ISO, IEC, CEN/CENELEC, ETSI, etc.) or 
planned  to  be.  However,  also  “de  facto”  standards  used  in  practice  by  the  industry  can  be 
included, if no official standard exists. 

Regarding the identification of existing standards developed by SDOs for implementation of DSF, the 
Invitation  to  Tender  of  the  EC  already  listed  SAREF  and  oneM2M  among  the  standards  to  be 
considered.  The  long  list  was  further  populated  using  the  criteria  mentioned  above  and  leveraging 
the comprehensive knowledge of the DSF study’s team members concerning the DSF standardisation 

Digital 
Single 
Market 

 
 
landscape. In addition, the input provided by the EC8 and industry stakeholders involved in European 
research projects9 was considered. 

To present the identified standards in a consistent and systematic way and provide the reader with a 
structured and easy to read overview of the state of standardisation for DSF, a common template to 
describe each standard in the long list was adopted, as it was done in the previous SAREF study [4]. 
The template consists of the following fields:  

o  Acronym/Full Name; 
o 
Issuing Organisation; 
o  Most relevant URL/ precise references; 
o  Overall description; 
o  Description of semantic coverage and main data elements; and 
o 

Interface covered in the end-to-end DSF flow. 

The second step was to narrow down the long list  to a short list of representative standards to be 
used in the rest of the study to further investigate the alignment of DSF standards10. The short list has 
been selected based on the following Shor List (SL) criteria: 

  Criterion  SL1:  The  standard  should  contain  data  definitions  that  allow  us  to  extract  data 
elements. For example, a standard like IEC TR 62746-2 (see Section 3.3.3), although relevant for 
this  study  and  the  interfaces  of  interest,  is  about  use  cases  and  provides  limited  input  to  the 
identification of data elements for alignments, therefore it is not included in the short list; 

  Criterion  SL2:  The  data  elements  covered  by  the  standard  should  match  (some  of)  the  data 
elements associated with the use cases in the scope of this study as described in Section 2.3.3; 

  Criterion  SL3:  The  standard  should  be  publicly  accessible  for  stakeholders  (e.g.,  via  a  URL). 
Industry standards that require one to become a member of an industry group to access them 
are  not  considered  in  this  study.  Open  (i.e.,  freely  available)  standards  are  preferred,  as  they 
facilitate accessibility for stakeholders, but this is not a mandatory requirement for inclusion in 
the short list; 

  Criterion SL4: The standard should preferably offer a machine-readable format that facilitates the 
extraction of data elements and the (automatic) alignment with SAREF concepts (e.g., ontologies 
in RDF/OWL, XSD schemas, UML diagrams). For example, standards that are only specified as PDF 
documents may be considered, but they are not preferred, as they entail a lot of manual effort to 
extract  the  semantics  from  text  and  tables,  which 
lead  to 
misinterpretations. 

is  error-prone  and  may 

The reader should be aware that this short list is not an endorsement by DNV-GL, TNO, ESMIG or the 
European  Commission,  nor  does  it  signify  anything  about  the  relevance  of  the  standards,  nor  any 

8 For example, the database on Smart Grid standardisation developed in the context of the STARGRID project 
(http://stargrid.eu). The web interface allows to search for documents (standards and related publications) or 
institutions (organisations and committees). 
9 For example, the H2020 Interflex project (http://interflex-h2020.com). 
10 Note that standards that are not included in our short list can also be aligned by the interested stakeholders 
following the alignment approach proposed in Section 4. 

Digital 
Single 
Market 

 
 
 
                                                            
other commercially valuable qualification. It simply provided a good basis to further proceed with the 
alignments. 

As a third step, a workshop has been conducted in the context of this study on the 19th of June 2017 
in Brussels (see Appendix B) to check with relevant stakeholders whether all the relevant standards 
for DSF were covered by our state of standardisation analysis,  and whether the proposed short list 
was sufficiently representative. As a result, two additional standards have been taken into account, 
in particular,  the KNX specification  has  been added to  the short list (see Section  3.3.2) and  the EFI 
specification to the long list (see Section 3.3.3).  

Finally,  it  has  been  specifically  assessed  whether  the  short-listed  standards  sufficiently  cover  the 
main data elements exchanged in the DSF flow as identified in task 1 (criterion SL2). The assessment 
was performed by comparing 1) the data elements associated with the main use cases (see Section 
2.3.3) with 2) SAREF and  SAREF4ENER  classes (see Section 3.3.2). It was  concluded that  SAREF and 
SAREF4ENER sufficiently cover the main data elements exchanged in the DSF flow and provide a good 
basis as a “common mapping tool” to the other short-listed standards. The alignment of the short-list 
standards via SAREF and SAREF4ENER as a common mapping tool is elaborated in Section 4.  

3.3  Technical analysis 
3.3.1  Long list of standards 
A long list of 19 existing standards developed by SDOs for implementation of DSF has been identified 
according to the approach described in Section 3.2. From this list, a short list of 10 standards suitable 
to  proceed  with  further  alignments  has  been  subsequently  selected.  The  long  list  of  identified 
standards  is  given  in  Table  3-1,  followed  by  a  short  description  of  the  issuing  SDOs  and  Technical 
Committees (TCs). The standards highlighted in bold are the short-listed standards. Each short-listed 
standard  is  described  in  detail  in  Section  3.3.2,  while  the  non-selected  standards  are  described  in 
Section 3.3.3. 

Table 3-1: Long list of standards identified in the DSF study 

# 

1 

2 

3 

4 

Reference/ Issued by 

URL 

CEN EN 13757 (TC 294 ) 
Communication systems for meters  

CEN EN 16836 (TC 294 )/ ZigBee SEP2 (ZigBee Alliance) 
Communication systems for meters - Wireless mesh 
networking for meter data exchange  

CENELEC EN 50491-11 (TC 205) 
General requirements for Home and Building Electronic 
Systems (HBES) and Building Automation and Control 
Systems (BACS) - Part 11: Smart Metering - Application 
Specifications - Simple External Consumer Display 
CENELEC prEN 50491-12 (TC 205) 
General requirements for Home and Building Electronic 
Systems (HBES) and Building Automation and Control Systems 
(BACS) - Smart grid  

https://standards.cen.eu/dyn/www/f?p=204:32:0::
::FSP_ORG_ID,FSP_LANG_ID:6275,25&cs=1A1D2A7
1837AB4AB1532B872DBD554033  

https://standards.cen.eu/dyn/www/f?p=204:32:0::
::FSP_ORG_ID,FSP_LANG_ID:6275,25&cs=1A1D2A7
1837AB4AB1532B872DBD554033 OR 
http://www.zigbee.org/about/centc294 

https://www.cenelec.eu/dyn/www/f?p=104:110:1
686791285416701::::FSP_ORG_ID,FSP_PROJECT,FS
P_LANG_ID:1258281,42730,25 

https://www.cenelec.eu/dyn/www/f?p=104:110:1
344658983181101::::FSP_ORG_ID,FSP_PROJECT,FS
P_LANG_ID:1258281,63376,25  

Digital 
Single 
Market 

 
 
 
# 

5 

6 

7 

8 

9 

10 

11 

12 

13 

Reference/ Issued by 

URL 

CENELEC prEN 50631-1 (TC59 WG7)  
Household appliances network and grid connectivity - Part 1: 
General Requirements, Generic Data Modelling and Neutral 
Messages 
EFI - Energy Flexibility Interface, FAN Alliance  (input to prEN 
50491-12-2, CLC TC 205 WG18) 

ETSI SAREF TS 103 264 (SmartM2M TC) 
SmartM2M; Smart Appliances; Reference Ontology and 
oneM2M Mapping 

https://www.cenelec.eu/dyn/www/f?p=104:110:1
438163728984601::::FSP_ORG_ID,FSP_PROJECT,FS
P_LANG_ID:1257245,47024,25  

https://github.com/flexiblepower/efi 

http://www.etsi.org/deliver/etsi_ts/103200_1032
99/103264/02.01.01_60/ts_103264v020101p.pdf  

ETSI SAREF4ENER TS 103 410-1 (SmartM2M TC) 
SmartM2M; Smart Appliances Extension to SAREF; Part 1: 
Energy Domain 

http://www.etsi.org/deliver/etsi_ts/103400_1034
99/10341001/01.01.01_60/ts_10341001v010101p.
pdf 

ETSI TR 103 411 (SmartM2M TC) 
SmartM2M; Smart Appliances; SAREF extension investigation 

http://www.etsi.org/deliver/etsi_tr/103400_1034
99/103411/01.01.01_60/tr_103411v010101p.pdf  

IEC 61968-9 CIM for Metering (TC 57 WG14) 
Common Information Model (CIM)/ Distribution 
Management 

http://www.iec.ch/smartgrid/standards/  

IEC 61970-301 CIM Core (TC 57) 
Common information model (CIM)/Energy Management 

http://www.iec.ch/smartgrid/standards/  

IEC/CENELEC 62056 COSEM (TC 13 WG 14) 
Electricity metering - Data exchange for meter reading, tariff 
and load control  

https://webstore.iec.ch/publication/34317 OR 
http://dlms.com/PASSWORD/Books/Blue_Book_1
1th_edition.pdf  

IEC TR 62746-2 (TC 57 WG21 )  
Systems interface between customer energy management 
system and the power management system  

https://webstore.iec.ch/publication/22279 

14 

IEC TS 62913-2-3 (TC8 SyC Smart Energy WG6) 
Generic Smart Grid Requirements 

15 

KNX specification for home building and control (KNX 
Association)/CENELEC EN 50090 (TC 205)  

http://www.iec.ch/dyn/www/f?p=103:38:7354931
541404::::FSP_ORG_ID,FSP_APEX_PAGE,FSP_PROJ
ECT_ID:11825,23,22240 

https://my.knx.org/en/shop/knx-specifications 

16 

oneM2M Functional Architecture TS 0001  

http://onem2m.org/technical/published-drafts  

17 

oneM2M Base Ontology TS 0012 and TS 0030 Ontology 
based Interworking 

http://onem2m.org/technical/published-drafts  

18  OpenADR Specification (OpenADR Alliance) 

http://www.openadr.org/specification 

19 

SPINE (Smart Premises Interoperable Neutral-message 
Exchange) Specification (EEBUS and Energy@home) 

https://www.eebus.org/en/downloads/ 

3.3.1.1 

Issuing SDOs and TCs 

CEN  (https://www.cen.eu)  is  the  European  Committee  for  Standardization,  one  of  the  three 
European  Standardization  Organizations  (together  with  CENELEC  and  ETSI).  CEN  supports 
standardization  activities  in  relation  to  a  wide  range  of  fields  and  sectors  including:  air  and  space, 
chemicals,  construction,  consumer  products,  defense  and  security,  energy,  the  environment,  food 

Digital 
Single 
Market 

 
 
 
 
 
 
 
and  feed,  health  and  safety,  healthcare,  ICT,  machinery,  materials,  pressure  equipment,  services, 
smart living, transport and packaging. The entire collection of CEN published and under development 
standards 
at 
be 
can 
https://standards.cen.eu/dyn/www/f?p=CENWEB:105::RESET  

Programme) 

searched 

online 

(Work 

  TC  294,  Communication  systems  for  meters  has  the  scope  to  standardize  communication 
interfaces  for  systems  with  meters  and  remote  reading  of  meters  for  all  kind  of  fluids  and 
energies distributed by network. Cooperation with CENELEC and ETSI for consistent interface 
definitions is essential condition for achieving interoperability between entities in systems. 

CENELEC (https://www.cenelec.eu/) is the European Committee for Electrotechnical Standardization 
and is responsible for standardization in the electrotechnical engineering field. The entire collection 
of  CENELEC  published  standards  and  standards  under  development  (Work  Programme)  can  be 
searched 
at 
http://www.cenelec.eu/dyn/www/f?p=104:105:748461397861594::::FSP_LANG_ID:25 

online 

  TC  59X,  Household  appliances  network  and  grid  connectivity  has  the  scope  to  prepare 
European Standards on methods of measurement of characteristics which are of importance 
to  determine  the  performance  of  electrical  appliances  for  household  use  or  of  electrical 
appliances  for  commercial  use  and  that  are  of  interest  for  the  user.  The  standards  are 
developed  to  suit  the  needs  of  EU  Regulations  and  Directives  and  in  the  context  of  the 
European market. 

  TC  205, Home  and Building  Electronic  Systems  (HBES)  has  the scope to  prepare  standards 
for all aspects of home and building electronic systems in relation to the Information Society. 
The scope is to ensure integration of a wide spectrum of control applications and the control 
and management aspects of other applications in and around homes and buildings. 

ETSI  (http://www.etsi.org/)  is  the  European  Telecommunications  Standards  Institute,  one  of  the 
three  European  Standardization  Organizations.  ETSI  produces  globally-applicable  standards  for 
Information  and  Communications  Technologies  (ICT),  including  fixed,  mobile,  radio,  converged, 
aeronautical,  broadcast  and  internet  technologies.  The  entire  collection  of  ETSI  standards  can  be 
searched online at http://www.etsi.org/standards-search.   

  SmartM2M  TC,  Smart  Machine-to-Machine  communications  is  responsible  for  the  SAREF 

standard and its related communication framework based on oneM2M.  

IEC  (http://www.iec.ch/)  is  the  International  Electrotechnical  Commission,  a  not-for-profit,  quasi-
governmental  organization  that  prepares  and  publishes  International  Standards  for  all  electrical, 
electronic and related technologies. The entire collection of IEC publications can be searched online 
at https://webstore.iec.ch/.  

  TC 8, Systems aspects for electrical energy supply has the scope to prepare and coordinate, 
in  co-operation  with  other  TC/SCs,  the  development  of  international  standards  and  other 
deliverables  with  emphasis  on  overall  system  aspects  of  electricity  supply  systems  and 
acceptable  balance  between  cost  and  quality  for  the  users  of  electrical  energy.  Electricity 
supply  system  encompasses  transmission  and  distribution  networks  and  connected  user 
installations (generators and loads) with their network interfaces. 

  TC  13,  Electrical  energy  measurement  and  control  does  standardization  in  the  field  of  a.c. 
and  d.c.  electrical  energy  measurement  and  control,  for  smart  metering  equipment  and 

Digital 
Single 
Market 

 
 
 
 
systems  forming  part  of  smart  grids,  used  in  power  stations,  along  the  network,  and  at 
energy  users  and  producers,  as  well  as  to  prepare  international  standards  for  meter  test 
equipment  and  methods.  Excluded  from  the  work  of  TC  13  is  the  standardization  for  the 
interface  of  metering  equipment  for  interconnection  lines  and  industrial  consumers  and 
producers (covered by TC 57). 

o  WG  14,  Data  exchange for  meter reading,  tariff  and  load control  in TC  13  has  the 
scope to establish standards, by reference to ISO/OSI Standards, necessary for data 
exchanges  by  different  communication  media,  for  automatic  meter  reading,  tariff 
and  load  control,  and  consumer  information.  The  media  can  be  either  distribution 
line  carrier  (DLC),  telephone  (including  ISDN),  radio  or  other  electrical  or  optical 
system and they may be used for local or remote data exchange. 

  TC 57, Power systems management and associated information exchange has the scope to 
prepare international standards for power systems control equipment and systems including 
EMS  (Energy  Management  Systems),  SCADA  (Supervisory  Control  And  Data  Acquisition), 
distribution automation, tele protection, and associated information exchange for real-time 
and  non-real-time  information,  used  in  the  planning,  operation  and  maintenance  of  power 
systems.  

o  WG  14,  System  interfaces  for  distribution  management  (SIDM)  in  TC  57  has  the 
scope to identify and establish requirements for standard interfaces of a Distribution 
Management System (DMS) based on an interface architecture. 

o  WG  21,  Interfaces  and  protocol  profiles  relevant  to  systems  connected  to  the 
electrical grid in TC 57 has the scope of identifying use cases which involve systems 
connected to the electrical grid. The focus is on interaction between power system 
management  (TC  57  standards)  and  home/building/industrial  (H/B/I)  energy 
management systems. 

oneM2M  (http://www.oneM2M.org)  is  the  global  standards  initiative  for  Machine  to  Machine 
Communications and the Internet of Things. It is a Global Partnership that includes 8 of the world's 
leading  ICT  standards  bodies,  6  global  fora  and  SDOs,  and  over  200  companies  from  all  industrial 
sectors.  The  purpose  and  goal  of  oneM2M  is  to  develop  technical  specifications  that  address  the 
need for a common M2M Service Layer that can be readily embedded within various hardware and 
software, and relied upon to connect the myriad of devices in the field with M2M application servers 
worldwide.  oneM2M  published  specifications  are  available 
for  download  at 
http://onem2m.org/technical/published-drafts.    

free 

for 

3.3.2  Short list of standards 
The following standards fulfil the criteria described in Section 3.2 and provide a suitable basis to 
further proceed with data element alignments: 

  CEN 16836 (ZigBee SEP2) 
  CENELEC EN 50491-11 Smart Metering 
  CENELEC EN 50631-1 (SPINE) 
  ETSI TS 103 264 (SAREF) 
  ETSI TS 103 410-1 (SAREF4ENER) 
 
IEC 61968-9 CIM for metering 
 
IEC 61970 CIM  

Digital 
Single 
Market 

 
 
IEC/CENELEC 62056 COSEM 

 
  CENELEC EN 50090 (KNX) 
  oneM2M TS 0012 Base Ontology 

3.3.2.1 

CEN EN 16836 (ZigBee SEP2) 

Standard Acronym and Full Name 
EN 16836 “Communication systems for meters - Wireless mesh networking for meter data exchange” 
Parts 1 to 3: 

  EN 16836-1:2016 “Communication systems for meters - Wireless mesh networking for meter 

data exchange - Part 1: Introduction and standardization framework” 

  EN 16836-2:2016 “Communication systems for meters - Wireless mesh networking for meter 

data exchange - Part 2: Networking layer and stack specification” 

  EN 16836-3:2016 “Communication systems for meters - Wireless mesh networking for meter 

data exchange - Part 3: Energy profile specification dedicated application layer” 

Issuing Organisation/ Technical Committee/ Industry Alliance 
CEN, the European Committee for Standardization, TC 294 Communication systems for meters (see 
Section 3.3.1). CEN TC 294 has a technical liaison agreement with the ZigBee Alliance 
(http://www.zigbee.org/) in order to exchange documents, share knowledge, and report on 
meetings. There is also a Memorandum Of Understanding (MOU) in place between the organizations 
under the Consortium Bridge procedure within CEN/CENELEC, which allows CEN and CENELEC to 
reference published ZigBee documents. This MOU allows CEN to produce an European Norm (EN) 
standards series referencing ZigBee documents so that the ZigBee Smart Energy standard can 
effectively be published as an EN standard within the context of CEN TC 294. 

Most relevant URLs, and other precise references 
The EN 16836 series is publicly available from the TC 294 Work Programme, the download requires 
credentials (standard to be purchased from CEN National Standardization Bodies (NSBs) for a fee):  

  EN 16836-1:2016 Part 1: Introduction and standardization framework 

https://standards.cen.eu/dyn/www/f?p=204:110:0::::FSP_PROJECT:41098&cs=144AD5A86F9
C7CD56BC47BB022D48A7DC 

  EN 16836-2:2016 Part 2: Networking layer and stack specification 

https://standards.cen.eu/dyn/www/f?p=204:110:0::::FSP_PROJECT:41099&cs=148DC18DC5
EF70796F3D6AFC57140D4E1  

  EN 16836-3:2016 Part 3: Energy profile specification dedicated application layer 

https://standards.cen.eu/dyn/www/f?p=204:110:0::::FSP_PROJECT:41100&cs=1B059B31255
F6A18CCBCF05239A915DB2  

The EN 16836 series parts 1 to 3 produced by CEN TC 294 references the following ZigBee 
documents, which can be freely downloaded at http://www.zigbee.org/about/centc294  after 
registration: 

  ZigBee Smart Energy Profile Specification Standard – 07-5356 Rev 19, December 3, 2014 
  ZigBee Cluster Library – 07-5123 Rev 04, April 26, 2010 
  ZigBee OTA Cluster Specification – 09-5264 Rev 23, March 12, 2014 

Digital 
Single 
Market 

 
 
 
 
 
  ZigBee Specification – 05-3474 Rev 20, September 7, 2012 
  ZigBee PRO Stack Profile – 07-4855 Rev 05, January 2008 

Overall description 
The  EN  16836  series  of  standards  provides  a  list  of  references  to  ZigBee  documents  in  compliance 
with  the  Bridge  Consortium  and  additionally  the  Memorandum  of  Understanding  between  the 
ZigBee  Alliance  and  CEN/CENELEC.  One  of  these  referenced  documents  is  ‘ZigBee  Smart  Energy 
Profile  Specification  Standard  –  07-5356  Rev  19,  December  3,  2014’,  which  defines  devices  and 
interfaces  for  Smart  Energy  applications  in  residential  or  light  commercial  environments,  ranging 
from  a  single  home  to  an  entire  apartment  complex.  A  neighbourhood  area  networks  is  used  for 
meters, where ZigBee is used for sub-metering within a home or apartment and for communication 
to  devices  within  the  home.  Note  that  for  security  reasons,  a  ZigBee  Smart  Energy  network, 
characterized  by  higher  security,  does  not  interact  with  a  consumer  ZigBee  Home  Area  Network, 
unless explicitly configured. 

Description of the semantic coverage and main data elements 
Main  areas  of  interest  for  the  ZigBee  Smart  Energy  Profile  specification  (so-called  “clusters” 
supported by the Energy Service Interface) are Metering, Price, Messaging, Demand Response/Load 
Control, Time. 

Concepts of interest for Metering include: 

  Commodities (such as electric, gas, water, and thermal) 
  Type of Meters 

o  Electric Metering 
o  Gas Metering 
o  Water Metering 
o  Thermal Metering (deprecated) 
o  Pressure Metering 
o  Heat Metering 
o  Cooling Metering 
o  End Use Measurement Device (EUMD) for metering electric vehicle charging 
o  PV Generation Metering 
o  Wind Turbine Generation Metering 
o  Water Turbine Generation Metering 
o  Micro Generation Metering 
o  Solar Hot Water Generation Metering 
o  Electric Metering Element/Phase 1 
o  Electric Metering Element/Phase 2 
o  Electric Metering Element/Phase 3 

  Units of measure for international support (such as kWh, kW, Watts, Cubic Meters, Cubic 

Feet, US Gallons, Imperial Gallons, Liters, etc.) 

  Measurement types (such as load profile, power factor, summation, demand, and tiers) 
  Real-time information 
  Historical information (previous day, today, etc.) 
  Status indicators (e.g. battery low, tamper detected) 

Digital 
Single 
Market 

 
 
 
 
 
  Generation (delivered) and consumption (received) 

Concepts of interest for Price include: 

  Block tariff (inclining/declining rates) 
  Prepayment 
  Commodities (e.g., electric, gas, water, and thermal) 
  Units of measure for international support 
  Multiple currencies for international support (using ISO 4217) 
  Generated (delivered) and consumed (received) prices 

Concepts of interest for Demand Response/Load Control include: 

  Events for specific groups of devices, such as HVAC Compressor or Furnace, Strip 

Heaters/Baseboard Heaters, Water Heater, Pool Pump/Spa/Jacuzzi, Smart Appliances, 
Irrigation Pump, Managed Commercial & Industrial (C&I) loads, Simple misc. (Residential 
On/Off) loads, Exterior Lighting, Interior Lighting, Electric Vehicle, Generation Systems.  
  Control methods, including temperature set points and offsets, criticality levels (such as 

emergency signals) and duty cycling. Criticality levels include: 

o  Green/ Voluntary (energy delivered uses an abnormal amount from non-“green” 

sources. Participation in this event is voluntary)  

o  Emergency/ Mandatory (participation in “Emergency” event is mandatory and the 
expected response is termination of all non-essential energy use, as defined by the 
utility) 

o  Planned Outage/ Mandatory (participation in “Planned Outage” event is mandatory 
and the expected response is termination of delivery of all non-essential energy, as 
defined by the utility) 

o  Service Disconnect/ Mandatory (participation in “Service Disconnect” event is 

mandatory and the expected response is termination of delivery of all non-essential 
energy, as defined by the utility) 

o  Utility Defined 

  Start and end times to avoid spikes 

Devices defined in the ZigBee Smart Energy Profile specification include: 

  Metering Device, i.e.,  meters (electricity, gas, water, heat, etc.) that can provide immediate  

 

readings (requested) or periodical readings (sent autonomously). They may also 
communicate status indicators (e.g. battery low, tamper detected). Supported cluster 
(mandatory): Metering. 
In-Home Display Device, i.e.,  graphical or text displays to show energy consumption data to 
the user (not necessarily with an interactive interface). Data to be displayed consists of 
current energy usage, a history over selectable periods, pricing information, or text 
messages. Also show critical pricing information may be shown to advise the customer when 
peaks are due to occur so that appropriate action can be taken. 

  Programmable Communicating Thermostat (PCT) Device to control the premises heating and 

cooling systems. Supported cluster (mandatory): Demand Response/Load Control.  

Digital 
Single 
Market 

 
 
 
 
 
 

Load Control Device, i.e.,  devices such as water heaters, exterior lighting, and pool pumps 
that can receive Demand Response and Load Control events to manage consumption on a 
range of devices. Supported cluster (mandatory): Demand Response/Load Control. 
  Range Extender Device, i.e., a simple device that acts as a router for other devices.  
  Smart Appliance device, i.e.,  smart appliances that can participate in energy management 
activities, for example, when Utilities initiate a demand response or pricing event, or the 
appliance actively informs customers via in-home displays of when or how energy is being 
used (e.g., Washer switching to cold water during periods of higher energy costs, 
Washer/Dryer/Oven/Hot Water Heater reporting cycle status, over-temperature conditions 
in Freezers and Refrigerators). Supported clusters (mandatory): Price, Time.  

  Prepayment Terminal Device, i.e., a device that accepts payment (e.g. credit card, code 

entry), display remaining balances, and alert the user of a balance approaching zero. This 
device is used to allow utility customers or other users (e.g. sub-metered tenants) to pay for 
consumption in discrete increments rather than establishing a traditional billing agreement. 
Supported clusters (mandatory): Price, Time, Prepayment. 

Interface covered in the end-to-end DSF flow 
Interface H2, H1 (see Figure 3-1). 

3.3.2.2 

CENELEC EN 50491-11 Smart Metering 

Standard Acronym and Full Name 
CENELEC EN 50491-11 “General requirements for Home and Building Electronic Systems (HBES) and 
Building Automation and Control Systems (BACS) - Part 11: Smart Metering - Application 
Specifications - Simple External Consumer Display” 

Issuing Organisation/ Technical Committee/ Industry Alliance 
CENELEC, European Committee for Electrotechnical Standardization, TC 205 Home and Building 
Electronic Systems (HBES) (see Section 3.3.1).  

Most relevant URLs, and other precise references 
The EN 50491-11 is a published standard currently available from the TC 205 Work Programme at 
https://www.cenelec.eu/dyn/www/f?p=104:110:1686791285416701::::FSP_ORG_ID,FSP_PROJECT,F
SP_LANG_ID:1258281,42730,25 . The download requires credentials. The standard can be purchased 
from CENELEC's National Committees and Affiliates for a fee.  

Overall description 
The EN 50491-11: 2015 standard specifies a data model to abstract the metering world towards a 
simple external consumer display. The data model, as described by means of functional blocks 
contained in EN 50491-11, lays down the format of metering data accessible by a simple external 
consumer display. This data interface would be typically part of the meter communication functions 
and be accessed by a simple external consumer display via the H1 interface of the CEN/CLC/ETSI TR 
50572 between the display and the meter communication functions (however, note that the same 
data model can be used also on the H2 interface). The EN 50491-11 standard specifies neither the 
communication mechanisms used on the data interface, nor the applied data privacy and security 
mechanisms nor the ergonomics of the simple external consumer displays, where national 

Digital 
Single 
Market 

 
 
 
 
 
 
regulations may apply. It does also not specify the communication protocol used between the meters 
and the meter communication functions. However, it considers the existing European standards like 
the EN 13757 series (in particular EN 13757-3:2013 and its Annex O) and the EN 62056 series for the 
definition of the data model. 

Description of the semantic coverage and main data elements 
The  main  concepts  addressed  in  EN  50491-11  are  those  of  Meter  (i.e.,  instrument  for  measuring, 
memorizing  and  displaying  data  related  to  the  consumption  of  a  commodity)  and  Data  Point  (i.e., 
container  element,  in  which  information  is  located  related  to  a  function  of  a  product).  Meters  are 
characterized  by  metering  functions.  Each  metering  function  is  represented  by  a  corresponding 
Functional  Block,  typically  part  of  the  metering  communication  function  and  accessed  by  a  simple 
user  display.  Some  meters  may  also  provide  metering  data  history  values  (e.g.  monthly  data).  A 
functional block is specified for each typical metering function, grouping a number of in- and output 
data  points.  Most  functional  blocks  of  the  data  interface  specified  in  the  EN  50491-11  standard 
contain data that are intended as output data to a connected display. 

Metering Functional Blocks:  

  The Functional Block ‘MDC Heat Meter’ contains heat meter data.  
  The Functional Block ‘MDC Heat Cost Allocator’ contains heat cost allocator data.  
  The Functional Block ‘MDC Water Meter’ contains water meter data.  
  The  Functional  Block  ‘MDC  Generic  Meter’  is  used  if  none  of  the  other  functional  blocks 

cover the desired metering medium (e.g. oil, steam, or other).  
  The Functional Block ‘MDC Gas Meter’ contains gas meter data.  
  The Functional Block ‘MDC Electricity Meter’ contains electricity meter data.  
  The Functional Block ‘MDC Breaker’ contains metering Breaker data.  
  The Functional Block ‘MDC Valve’ contains Valve data. 

Datapoints  for  the  functional  blocks  mentioned  above 
include:  CurrentEnergyConsumption, 
TempFlowWater  (Current  flow  temperature),  TempReturnWater  (Current  Return  temperature), 
TempDiffWater    (Current  Temperature  difference),  CurrentVolumeConsumption,  CurrentPower, 
HistoryEnergyConsumption, 
DeviceType, 
Manufacturer,  IdentificationNumber  ,  VersionNumber,  CurrentDate,  MaxPowerDate,  MaxPower, 
MinPowerDate, MinPower, Currency, Accumulated Cost, Current Credit.  

HistoryMinPower,  Metering 

HistoryMaxPower, 

Measurable  quantities  that  can  be  represented  in  the  data  interface  through  the  functional  blocks 
mentioned above are the following: Oil, Electricity, Gas, Heat (outlet), Steam, Warm Water (30°C to 
90°C),  Water,  Heat  cost  allocator,  Cooling  Load  meter  (outlet),  Cooling  Load  meter  (inlet),  Heat 
(inlet), Heat and Cool, Breaker, Valve, Waste water meter.  

Interface covered in the end-to-end DSF flow 
H1, H2 (see Figure 3-1). 

3.3.2.3 

CENELEC EN 50631-1 

Standard Acronym and Full Name 

Digital 
Single 
Market 

 
 
 
 
 
 
 
CENELEC  prEN  50631-1  “Household  appliances  network  and  grid  connectivity  -  Part  1:  General 
Requirements,  Generic  Data  Modelling  and  Neutral  Messages”  is  part  of  the  upcoming  EN  50631 
standard that will further comprise the following parts: 

  prEN  50631-2-x:  Household  appliances  network  and  grid  connectivity  -  Product  Specific 

Requirements and Specifications; 

  prEN  50631-3:  Household  appliances  network  and  grid  connectivity  -  General  Test-

Requirements and Specifications;  

  prEN  50631-4-x:  Household  appliances  network  and  grid  connectivity 

-  Specific 

Implementation and Test Requirements. 

Issuing Organisation/ Technical Committee/ Industry Alliance 
CENELEC,  European  Committee  for  Electrotechnical  Standardization,  TC  59X  Household  appliances 
network and grid connectivity (see Section 3.3.1), WG7 Smart Household Appliances. 

Most relevant URLs, and other precise references 
The  prEN  50631-1  is  a  published  draft  currently  available  from  the  TC  59X  Work  Programme  at 
https://www.cenelec.eu/dyn/www/f?p=104:110:1438163728984601::::FSP_ORG_ID,FSP_PROJECT,F
SP_LANG_ID:1257245,47024,25. The download requires credentials. The standard can be purchased 
from CENELEC's National Committees and Affiliates for a fee. The prEN 50631-1 draft is currently in 
the ‘Approval stage’ status and its Date of Publication (DOP) is estimated for 2018-05-14.  

The  data  model  in  the  prEN  50631-1  draft  is  based  on  the  “Smart  Premises  Interoperable  Neutral-
Message Exchange (SPINE)” specification published by the EEBUS and Energy@Home associations at 
https://www.eebus.org/en/downloads/  (see  Section  3.3.3  for  the  most  relevant  URLs  and  other 
precise references on SPINE, EEBUS and Energy@Home).  

Overall description 
The  EN-50631  standard  focuses  on  interoperability  on  information  exchange  among  various 
appliances  in  the  home.  It  describes  the  necessary  control  and  monitoring,  and  defines  a  set  of 
functions of household and similar electrical appliances. The functions in this standard cover, next to 
energy-management, main remote-control and monitoring use cases. The prEN 50631 Part 1 (draft) 
defines generic data modelling and generic neutral messages for interoperable connected household 
appliances, without relation to any specific communication technology or any product specific layout. 
Part 2 will list and specify product specific requirements and implementation guidance based on the 
generic  data  model  and  generic  neutral  messages.  Part  3  will  define  Test-Requirements  and  Test-
Specifications.  Part  4  will  define  the  mapping  of  neutral  messages  to  examples  of  typical 
communication protocols like ZigBee, KNX, OIC, SHIP, Echonet light, Thread and so forth. 

Description of the semantic coverage and main data elements 
The  prEN  50631-1  draft  defines  data  models  for  Interoperable  Connected  Household  Appliances. 
Household  appliances  designate  equipment  intended  for  housekeeping  functions  such  as  washing, 
cleaning,  heating,  cooling,  cooking,  etc.  and  appliances  intended  for  use  in  the  home  environment 
such as shavers, hair care appliances, food preparation appliances, etc. Appliances for household use 
cover use by non-expert users in similar conditions as in households, for example, in shops, offices or 
other similar  work environments;  in farm  houses;  by  clients  in hotels,  motels  and  other residential 

Digital 
Single 
Market 

 
 
 
 
 
 
type  of  environments;  in  bed  and  breakfast  type  environments,  which  are  also  considered  as 
household appliances.  

The data model in the prEN 50631-1 draft is based on the  “Smart Premises Interoperable Neutral-
Message  Exchange  (SPINE)”  specification.  The  prEN  50631-1  draft  standard  provides  normative 
schemas (expressed as XSDs) for the following SPINE classes: Actuator Switch, Binding Management, 
Command  Common  Definitions,  Command  Frame,  Common  Data  Types,  Datagram,  Device 
Classification, Direct Control, Load Control, Measurement, Messaging, Network Management, Node 
Management, Operating Constraints, Power Sequences, Result, Sensing, Smart Energy Management 
Ps, Specific Device Entity Definitions, Subscription Management, Task Management, Threshold, Time 
Information, Time Table, Version (see dedicated description in Section 3.3.3 for details on SPINE).  

Interface covered in the end-to-end DSF flow 
S2, S1 (see Figure 3-1). 

3.3.2.4 

ETSI TS 103 264 (SAREF) 

Standard Acronym and Full Name 
ETSI SAREF TS 103 264 “SmartM2M; Smart Appliances; Reference Ontology and oneM2M Mapping”. 

Issuing Organisation/ Technical Committee/ Industry Alliance 
ETSI,  European  Telecommunications  Standards 
communications (SmartM2M) (see Section 3.3.1). 

Institute,  TC  Smart  Machine-to-Machine 

Most relevant URLs, and other precise references 
The  latest  SAREF  specification  TS  103  264  V2.1.1  (2017-03)  can  be  downloaded  for  free  from 
http://www.etsi.org/deliver/etsi_ts/103200_103299/103264/02.01.01_60/ts_103264v020101p.pdf.  
The ontology file is available from https://w3id.org/saref, which is a persistent URL11 run by the W3C 
Permanent Identifier Community Group12 that re-directs to http://ontology.tno.nl/saref. 
Examples of  how to create SAREF devices (i.e.,  data instances of actual devices compliant with the 
SAREF specification) are available at http://ontology.tno.nl. 

Overall description 
The first SAREF specification for smart appliances was published by ETSI SmartM2M TC in November 
2015  as  TS  103  264  V1.1.1  (2015-11)13.  This  specification  was  based  on  the  Smart  Appliance 
REFerence ontology (SAREF) that was originally created in the context of the SMART 2013/0077 study 
promoted by the European Commission (DG Connect) and conducted by TNO in collaboration with 
ETSI TC SmartM2M (https://sites.google.com/site/smartappliancesproject).  

11 A persistent URL acts as a permanent identifier in the face of a dynamic and changing Web infrastructure. The 
purpose is to provide a secure, permanent URL re-direction service for Web applications. This capability provides 
continuity of references to network resources that may migrate from machine to machine for business, social or 
technical reasons, ensuring that applications using persistent URLs will always be re-directed to a working 
website. 
12 https://www.w3.org/community/perma-id/  
13 http://www.etsi.org/deliver/etsi_ts/103200_103299/103264/01.01.01_60/ts_103264v010101p.pdf  

Digital 
Single 
Market 

 
 
 
 
 
 
 
 
                                                            
The study was motivated by the need of the market to reduce the energy utilization by managing and 
controlling  smart  appliances  (for  example,  in  a  house  or  an  office  building)  on  a  system  level.  The 
industry  and  the  European  Commission  identified  the  need  for  a  common  architecture  with 
standardized  interfaces  and  a  common  data  model  to  assure  interoperability.  Without  these  two 
components,  the  market  would  continue  to  be  fragmented  and  powerless.  Therefore,  the 
development  of  a  reference  ontology  was  targeted  as  the  main  interoperability  enabler  for 
appliances relevant for energy efficiency, and ETSI accepted to cover the communication aspect and 
provide  the  necessary  standardization  process  support.  As  a  result,  following  a  broad  consultation 
with stakeholders to address clear market needs, the European Commission financially supported the 
SMART 2013/0077 study for the creation of SAREF, which was completed on April 1st 2015.  

The  outcomes  of  the  study  [4]  were  then  transferred  to  ETSI  TC  SmartM2M  to  turn  the  SAREF 
ontology into an ETSI Technical Specification, published in November 2015 (TS 103 264 V1.1.1). This 
specification  subsequently  evolved  in  a  new  version  published  in  March  2017  (TS  103  264  V2.1.1), 
which considers the feedback received from the industrial stakeholders since its first release in April 
2015. The TS 103 264 V2.1.1 contains the specification of SAREF 2.0, including the changes compared 
to  the  previous  version,  and  an  updated  mapping  to  the  oneM2M  Base  Ontology  developed  in 
collaboration with oneM2M experts (see Section 3.3.2 for details on the oneM2M Base Ontology). 

Description of the semantic coverage and main data elements 
SAREF is based on the following main concepts (in alphabetical order): 

  Command, which is a directive that a device shall support to perform a certain function (e.g. 
On Command, Off Command, Pause Command,  Get Command,  Notify Command, Set Level 
Command); 

  Commodity,  which  is  a  marketable  item  for  which  there  is  demand,  but  which  is  supplied 

without qualitative differentiation across a market (e.g. Electricity, Gas, Water); 

  Device,  which  is  a  tangible  object  designed  to  accomplish  a  task  in  households,  common 

public buildings or offices (e.g. Switch, Meter, Sensor, Washing Machine); 

  Function,  which  is  the  functionality  necessary  to  accomplish  the  task  for  which  a  device  is 
designed (i.e., Actuating Function, Event Function, Metering Function, Sensing Function); 
  Measurement, which is the measured value made over a property. It is also linked to the unit 

of measure in which the value is expressed and to the timestamp of the measurement; 
  Profile, which is a specification associated to a device to collect information about a certain 
property or commodity (e.g., Energy or Water) for optimizing its usage in the home/building 
in which the device is located; 

  Property,  which  is  anything  that  can  be  sensed,  measured  or  controlled  in  households, 
common public buildings or offices (e.g., Energy, Humidity, Light, Motion, Occupancy, Power, 
Pressure, Price, Smoke, Temperature, Time); 

  Service,  which  is  a  representation  of  a  function  to  a  network  that  makes  the  function 
discoverable,  registerable  and  remotely  controllable  by  other  devices  in  the  network  (e.g., 
Switch On Service); 

  State, which is the state in which a device can be found (e.g., On Off State, Open Close State, 

Start Stop State, Multi Level State); 

  Task, which is the goal for which a device is designed, from a user perspective (e.g. Cleaning, 

Comfort, Lighting, Safety, Entertainment, Energy Efficiency); and  

Digital 
Single 
Market 

 
 
 
 
  UnitOfMeasure, which is a standard for measurement of a quantity, such as a Property. For 
example,  Power  is  a  property  and  Watt  is  a  unit  of  power  that  represents  a  definite 
predetermined power (e.g. Currency, Energy Unit, Power Unit, Temperature Unit). 

Interface covered in the end-to-end DSF flow 
S2, S1 (see Figure 3-1). 

3.3.2.5 

ETSI TS 103 410-1 (SAREF4ENER) 

Standard Acronym and Full Name 
ETSI  SAREF4ENER  TS  103  410-1  “SmartM2M;  Smart  Appliances  Extension  to  SAREF;  Part  1:  Energy 
Domain”. 

Issuing Organisation/ Technical Committee/ Industry Alliance 
ETSI,  European  Telecommunications  Standards 
communications (SmartM2M) (see Section 3.3.1). 

Institute,  TC  Smart  Machine-to-Machine 

Most relevant URLs, and other precise references 
The  SAREF4ENER 
from 
http://www.etsi.org/deliver/etsi_ts/103400_103499/10341001/01.01.01_60/ts_10341001v010101p.
pdf. The ontology file is available from https://w3id.org/saref4ener which is a persistent URL that re-
directs to http://ontology.tno.nl/saref4ener. 

(2017-02)  can  be  downloaded 

specification  V1.1.1 

free 

for 

Overall description 
TS 103 410-1 is a technical specification of SAREF4ENER, an extension of SAREF that was created in 
collaboration  with  Energy@Home14  and  EEBUS15,  the  major  Italy-  and  Germany-based  industry 
associations, to enable the interconnection of their (different) data models. SAREF4ENER is meant to 
enable interoperability among various proprietary solutions developed by different consortia in the 
smart home domain. By using SAREF4ENER, smart appliances from manufacturers that support the 
EEBUS  or  Energy@home  data  models  can  easily  communicate  with  each  other  using  any  energy 
management system at home or in the cloud.  To that end, SAREF4ENER should be used to annotate 
(or generate) a neutral (protocol-independent) set of messages to be directly adopted by the various 
manufacturers, or mapped to their  domain specific protocols of choice. SAREF4ENER is an OWL-DL 
ontology  that  extends  SAREF  with  63  classes,  17  object  properties  and  40  data  type  properties. 
SAREF4ENER focuses on demand response scenarios, in which customers can offer flexibility to the 
Smart Grid to manage their smart home devices by means of a Customer Energy Manager (CEM). The 
CEM is a logical function for optimizing energy consumption and/or production that can reside either 
in  the  home  gateway  or  in  the  cloud.  Moreover,  the  Smart  Grid  can  influence  the  quantity  or 
patterns of use of the energy consumed by customers when energy-supply systems are constrained, 
e.g. during peak hours. These scenarios involve the use cases described in TR 103 411 “SmartM2M; 
Smart Appliances; SAREF extension investigation” (see Section 3.3.3 for details on TR 103 411 and the 
use cases underlying SAREF4ENER). 

Description of the semantic coverage and main data elements 

14 http://www.energy-home.it  
15 https://www.eebus.org/?lang=en  

Digital 
Single 
Market 

 
 
 
 
 
 
 
                                                            
The  main  concepts  covered  by  SAREF4ENER  are  Device,  Power  Profile,  Alternatives  Group,  Power 
Sequence and Slot. A Power Profile in SAREF4ENER extends the more generic  Profile class in SAREF 
with  additional  properties  that  are  specific  for  smart  energy  management.  The  power  profile  in 
SAREF4ENER  is  used  by  a  device  to  expose  the  power  sequences  (or  plans)  that  are  potentially 
relevant  for  the  CEM.  To  that  end,  a  power  profile  consists  of  one  or  more  groups  (each  group 
modelled as an AlternativesGroup class) with alternative power sequences. Within one group, there 
can be one or more power sequences that are alternatives to each other, where at most one of these 
alternatives  can  be  finally  executed.  Power  sequences  may  have  further  options  with  regards  to 
flexibility, for example, one of the alternatives may offer that the CEM can pause a power sequence, 
if the sequence completes before the latest time set by the user. Finally, a power sequence consists 
of one or more slots that represent different phases of consumption (or production) and their values. 
Power  sequences  of  a  heating  system,  for  example,  typically  have  a  single  slot  each,  while  other 
devices such as washing machines, may have a power sequence with various slots for the different 
phases of washing, e.g., heating the water, washing and rinsing. 

SAREF4ENER also defines how to model events used in, for example, a direct load management and 
power curtailing scenarios, as reaction to special requests from the Smart Grid, such as incentives to 
consume depending on current energy availability, or emergency situations that require temporary 
reduction  of  the  power  consumption  (see  TR  103  411  in  Section  3.3.3  for  further  details  on  these 
scenarios). The classes of interest defined in SAREF4ENER for these scenarios are the following: 

 

 

 

 

LoadControlEventData is used to represent overload warning severity level and related load 
control  commands  to  a  device.  It  is  characterized  by  an  event  ID  and  a  timestamp  that 
represents  the  time  the  event  information  instance  was  created  or  received,  and  the  time 
period that denotes the period of validity of the event. For example, an event was received 5 
minutes ago, notifying that the considered event shall take effect tomorrow from 2:00 p.m. 
to  3:30  p.m.  (where  the  timestamp  of  this  event  is  "5  minutes  ago"  and  time  period  is 
"tomorrow 2:00 p.m. to 3:30 p.m."); 
LoadControlEventAction expresses the type of actions to be performed as a consequence of a 
load  control  event.  These  actions  can  be  of  type  "consume"  or  "produce"  to  denote 
consumption  or  production  of  energy  or  power.  Values  that  can  be  assumed  by  both 
consume and produce actions can be emergency, increase, normal, pause, reduce, resume;  
LoadControlStateData expresses the data about the state of an event and is characterized by 
an event ID (the same used for the corresponding event in the LoadControlEventData class) 
and a timestamp;  
LoadControlEventState is associated to LoadControlState, which expresses the possible states 
of a load control event. These states can be of type "consume" or "produce" (analogously to 
the  load  control  actions  mentioned  above).  Values  that  can  be  assumed  by  both  consume 
and  produce  states  can  be  eventAccepted,  eventStarted,  eventStopped,  eventRejected, 
eventCancelled, or eventError. 

Interface covered in the end-to-end DSF flow 
S2, S1 (see Figure 3-1). 

3.3.2.6 

IEC 61970 CIM  

Standard Acronym and Full Name 

Digital 
Single 
Market 

 
 
 
 
IEC 61970 Common Information Model (CIM)/Energy Management series of standards: 

 
 
 

 

IEC 61970-1 Part 1: Guidelines and general requirements; 
IEC 61970-2 Part 2: Glossary; 
IEC 61970-3XX Part 3XX: Common Information Model (CIM)  IEC 61970-301 (Core CIM); 
IEC 61970-4XX Part 4XX: Component Interface Specification (CIS); 
IEC 61970-5XX Part 5XX: CIS Technology Mappings  IEC 61970-501 (CIM RDF Schema). 

Issuing Organisation/ Technical Committee/ Industry Alliance 
IEC, International Electrotechnical Commission, TC57 - Power systems management and associated 
information exchange (see Section 3.3.1). 

Most relevant URLs, and other precise references 
IEC  61970-301:2016 
at 
https://webstore.iec.ch/publication/31356.  The  standard  is  not  available  for  free,  but  it  has  to  be 
purchased from IEC. 

a  published 

(Core  CIM) 

currently 

standard 

available 

is 

Overall description 
The IEC 61970-301 standard (Core CIM) lays down the common information model (CIM), which is an 
abstract model that represents all the major objects in an electric utility enterprise typically involved 
in utility operations. By providing a standard way of representing power system resources as object 
classes and attributes, along with their relationships, the CIM facilitates the integration of network 
applications developed independently by different vendors, between entire systems running network 
applications developed independently, or between a system running network applications and other 
systems  concerned  with  different  aspects  of  power  system  operations,  such  as  generation  or 
distribution  management.  The  CIM  facilitates  integration  by  defining  a  common  language  (i.e. 
semantics)  based  on  the  CIM  to  enable  these  applications  or  systems  to  access  public  data  and 
exchange information independent of how such information is represented internally. 

Description of the semantic coverage and main data elements 
The CIM standard is currently maintained as a UML class model. It defines a common vocabulary and 
basic  ontology  for  aspects  of  the  electric  power  system.  It  defines  about  1500  different  concepts 
(classes) and a multitude of properties divided over some 100 packages.  

The  metering  profile  in  CIM  contains  core  information  classes  representing  metering,  end-devices 
and other related concepts such as: 

  UsagePoint:  a  specialised  subclass  of  IdentifiedObject.  A  UsagePoint  is  a  representation 
logical  or  physical  point  in  the  network  to  which  readings  may  be  attributed.  Used  at  the 
place where a physical- or virtual meter may be located; however, it is not required that  a 
meter device is present. 

  UsagePointLocation:  a  specialised  subclass  of  Location.  The  location  of  an  individual  usage 
point  is  modelled  as  a  UsagePointLocation,  which  is  a  specific  type  of  Location  in  CIM.  A 
UsagePoint  is  the  place,  scene,  or  point  of  something  (e.g.,  address-,  electronic-  of  GPS-
location are examples of locations). Example of a UsagePoint is the place where a physical or 
virtual  meter  is  located  in  the  power  system.  It  can  be  defined  with  one  or  more  position 
points (coordinates) in a given coordinate system. 

Digital 
Single 
Market 

 
 
 
 
 
 
 
  Meter:  a  specialised  subclass  of  EndDevice.  A  Meter  is  defined  as  a  physical  asset  that 
represents the physical attributes of a meter EndDevice and enables the implementation of 
MeterReading  at  a  specific  UsagePoint,  used  for  measuring  consumption  and  detection  of 
EndDeviceEvent.  A  Meter  specializes  the  concept of  EndDevice,  which is  an  AssetContainer 
that performs one or more end device functions. One specific type of EndDevice is a Meter 
which can perform metering and optional other EndDeviceFunction like, load management, 
connect/disconnect, accounting functions, etc. Other type of EndDevice, such as monitoring 
and controlling air conditioner, refrigerator and pool pumps may be connected to a Meter as 
well.  All  EndDevice  may  have  communication  capability  defined  by  the  associated 
communication function(s). 

  MeterReading: Set of  values  obtained from  a  meter  EndDevice.  A  MeterReading is  a  set  of 

values obtained via the Meter.  

  Reading: Specific value measured by a meter or other asset, or calculated by a system. Each 
Reading in the set of MeterReading is a specific value measured by a Meter, or calculated by 
a  system.  Each  Reading  is  associated  with  a  specific  ReadingType.  An  example  of  a 
ReadingType is an individual- or regular 15-minutes interval reading. 

  Channel: a single path for the collection or reporting of register values over a period; 
  Register:  a  device  that  indicates  or  records  units  of  the  commodity  or  other  quantity 

measured. 

Interface covered in the end-to-end DSF flow 
Interface G3 (see Figure 3-1). 

3.3.2.7 

IEC 61968-9 CIM for metering 

Standard Acronym and Full Name 
IEC  61968  “Application 
management” Parts 1 to14: 

integration  at  electric  utilities  -  System 

interfaces  for  distribution 

 
 
 
 
 

 
 
 
 
 

 

 
 

IEC 61968-1 “Part 1: Interface architecture and general recommendations” [Published]; 
IEC 61968-2 “Part 2: Glossary” [Published]; 
IEC 61968-3 “Part 3: Interface for Network Operations” [Published];  
IEC 61968-4 “Part 4: Interfaces for Records and Asset management” [Published]; 
IEC  61968-5  “Part  5:  Interfaces  for  Operational  planning  and  optimization”  [Under 
Development]; 
IEC 61968-6“Part 6: Interfaces for Maintenance and Construction” [Published]; 
IEC 61968-7 “Part 7: Interfaces for Network Extension Planning” [Under Development]; 
IEC 61968-8 “Part 8: Interface Standard for customer Support” [Published]; 
IEC 61968-9 “Part 9: Interfaces for meter reading and control” [Published];  
IEC  61968-10  “Part  10: 
management” [Retired]; 
IEC  61968-11  “Part  11:  Common  Information  Model  (CIM)  Extensions  for  Distribution” 
[Published]; 
IEC 61968-12 “Part 12: Common Information Model (CIM) Use Cases for 61968” [Retired]; 
IEC  61968-13  “Part  13:  Common  Information  Model (CIM)  RDF  Model exchange format  for 
distribution” [Published]; 

Interfaces  for  Business  functions  external  to  distribution 

Digital 
Single 
Market 

 
 
 
 

IEC 61968-14 “Part 14: MultiSpeak – CIM Harmonization” [Published]. 

Issuing Organisation/ Technical Committee/ Industry Alliance 
IEC,  International  Electrotechnical  Commission,  TC57-  Power  systems  management  and  associated 
information  exchange,  WG14-  System  interfaces  for  distribution  management  (SIDM)  (see  Section 
3.3.1). 

IEC  61968-2:  2011 

Most relevant URLs, and other precise references 
The 
currently  available  at 
https://webstore.iec.ch/publication/6201 . The IEC 61968-9: 2013 (CIM for metering) is a published 
standard  currently  available  at  https://webstore.iec.ch/publication/6204.  These  standards  are  not 
available for free, but they can be purchased from IEC. 

is  a  published 

(Glossary) 

standard 

Overall description 
IEC 61968 is a series of standards under development for information exchanges between electrical 
distribution  systems.  These  standards  are  being  developed  by  Working  Group  14  of  Technical 
Committee  57  of  the  IEC.  IEC  61968  is  intended  to  support  the  inter-application  integration  of  a 
utility  enterprise  that  needs  to  collect  data  from  different  applications  that  are  legacy  or  new  and 
each  has  different  interfaces  and  run-time  environments.  IEC  61968  defines  interfaces  for  all  the 
major  elements  of  an  interface  architecture  for  Distribution  Management  Systems  (DMS)  and  is 
intended to be implemented with middleware services that broker messages among applications.  
The part of the IEC 61968 standard that is of interest in the scope of the DSF study to extract data 
elements is Part 9 (CIM for metering).  

The  IEC  61968-9  standard  specifies  the  information  content  of  a  set  of  message  types  that  can  be 
used to support many of the business functions related to meter reading and control. Typical uses of 
the  message  types  include  meter  reading,  controls,  events,  customer  data  synchronization  and 
customer  switching.  The  purpose  of  IEC  61968-9  is  to  define  a  standard  for  the  integration  of 
metering systems (MS), which includes traditional manual systems, and (one or two-way) automated 
meter  reading (AMR) systems,  and  meter data  management (MDM)  systems  with other enterprise 
systems  and  business  functions  within  the  scope  of  IEC  61968.  The  scope  of  IEC  61968-9  is  the 
exchange  of  information  between  metering  systems,  MDM  systems  and  other  systems  within  the 
utility enterprise. 

Description of the semantic coverage and main data elements 
A  Meter  is  a  specialization  of  an  End  Device  in  CIM.  From  the  perspective  of  the  IEC  61968-9 
standard,  a  meter  is  an  end  device  that  has  metrology  capability,  may  have  communications 
capability,  may  be  a  load  control  unit  and  may  host  a  mixture  of  other  different  types  of 
functionality. The following information about the meter is of interest for the IEC 61968-9 standard: 

is managed as a physical asset 

  has a unique identity (mRID and/or one or more instances of the Names class) 
 
  may issue events 
  may receive control requests 
  may collect and report measured values 
  may participate in utility business processes 

Digital 
Single 
Market 

 
 
 
 
 
 
 
A  meter  records  the  data  used  for  tariffing  public  networks,  and  data  used  for  network  balancing 
mechanisms. Readings captured by the metering system are collected by a system such as the Meter 
Data  Management  (MDM)  before  being  presented  for  billing  purposes.  Billing  entities  may  correct 
the  data,  or,  in  some  regions,  the  energy  supplier  may  perform  validating,  editing,  and  estimating 
(VEE)  according  to  rules  established  by  the  appropriate  supervising  regulatory  agency.  In  any  case, 
those corrections are made available to the user who requests them. 

Given  that  a  meter  has  metrology  capability,  electricity  meters  measure  kWh,  but  will  possibly 
measure  also  demand,  reactive  energy  and  demand,  time  of  use  quantities,  interval  data, 
engineering quantities and more. Analogously, meters for other commodities such as gas and water 
may monitor analogous quantities. 

Data  exchanged  via  the  interfaces  for  Meter  Reading  and  Control  specified  in  IEC  61968-9  include 
meter readings and status, outage detection and restoration verification data, power reliability and 
quality events, communication network health information for maintenance of the communications 
network,  configuration  and  installation  of  meters  (i.e.,  Meter  Asset  Management,  or  Asset 
Management in general), control and reconfiguration information (such as meter control commands, 
communicating  payment  system  information,  tariff  units  of  measure  and  calendar,  power  quality 
measurement, meter event recording, load control signals, meter identity and security credentials), 
load control signals in order to control the load presented by the EndDevice(s) and pricing signals in 
order to affect the load presented by the EndDevice(s) (for both economic and emergency reasons). 
Functionality related to customer care and billing is a subject external to the IEC 61968-9 standard. 
The billing function is driven by readings, typically demand or time-of-use, obtained from the meter. 

The information model relevant to meter reading and control consists of classes defined in the IEC 
61968-9 standard. In particular, the IEC 61968-9 standard makes use of the following classes: 

  Classes described as type "Asset", which are defined in the 61968/Assets package of the CIM 
  Classes described as type "Customer", which are defined in the 61968/Customers package of 

the CIM. 

  Classes described as type "Metering", which are defined in the 61968/Metering package of 

the CIM. 

  Classes  described  as 

type 

“PaymentMetering”,  which  are  described 

in 

the 

61968/PaymentMetering” package of the CIM. 

class 

(i.e.,  profile 

the  ComModuleConfig 

  Classes described as type "Profile", which are contextual profiles defined for 61968-9. These 
classes include, among others, the AuxiliaryAgreementConfig class (i.e.,  message profile for 
AuxiliaryAgreements), 
configuring 
communications modules), the EndDeviceControls class (i.e., message used to convey one or 
more  EndDeviceControls),  the  MeterConfig  class  (i.e.,  message  profile  for  Meter 
configuration  messages),  the  CustomerAccountConfig  class  (i.e.,  message  profile  for 
CustomerAccount), the MeterReadings class (i.e., profile for conveying MeterReadings), the 
MeterServiceRequests  class  (i.e.,  requests  that  can  be  used  for  a  variety  of  meter  service 
related  activities 
installation,  meter  change  out,  customer 
disconnect/reconnect,  ,  etc.),  the  PricingStructureConfig  class  (i.e.,  profile  for  configuring 
pricing  structures),  the  UsagePointLocationConfig  and  UsagePointConfig  classes  (i.e., 
messages used to establish associations to UsagePointLocations).  

include  meter 

that 

for 

Digital 
Single 
Market 

 
 
Interface covered in the end-to-end DSF flow 
H1, H2 (see Figure 3-1). 

3.3.2.8 

IEC 62056 COSEM 

Standard Acronym and Full Name 
IEC  62056  DLMS/COSEM  (Device  Language  Message  Specification  /  Companion  Specification  for 
Energy Metering) suite: 

 

 

IEC 62056-6-1 “Electricity metering data exchange - The DLMS/COSEM suite - Part 6-1: Object 
Identification System (OBIS)”; 
IEC  62056-6-2  “Electricity  metering  data  exchange  -  The  DLMS/COSEM  suite  -  Part  6-2: 
COSEM interface classes”; 

Issuing Organisation/ Technical Committee/ Industry Alliance 
IEC,  International  Electrotechnical  Commission,  TC13  -  Electrical  energy  measurement  and  control, 
WG14 - Data exchange for meter reading, tariff and load control (see Section 3.3.1).  

62056-6-1:2017 

Most relevant URLs, and other precise references 
IEC 
at 
https://webstore.iec.ch/publication/32782.  IEC  62056-6-2:2017  (COSEM  interface  classes)  is  a 
published standard currently available at https://webstore.iec.ch/publication/34317.These standards 
are not available for free and they have to be purchased from IEC. 

published 

currently 

standard 

available 

(OBIS) 

is 

a 

Note  that  IEC  62056-6-2  matches  the  “Companion  Specification  for  Energy  Metering:  COSEM 
interface classes and OBIS identification system” (also called “Blue Book” specifications) from DLMS 
User 
at 
2014, 
http://dlms.com/documentation/index.html. 

for  members 

Association, 

September 

available 

only 

27 

Overall description 
DLMS/COSEM  (Device  Language  Message  Specification  /  Companion  Specification  for  Energy 
Metering)  is  a  world-wide  standard  that  specifies  smart  meter  functionality.  It  is  developed  and 
maintained by the DLMS User Association16.  

DLMS is a generalized concept for abstract modelling of communication entities. It is a middleware 
protocol that can be applied on various physical layer technologies, such as Zigbee, M-bus, but also 
Internet. It is designed to support messaging to and from (energy) distribution devices in a computer-
integrated  environment.  Applications  like  remote  meter  reading,  remote  control  and  value  added 
services for metering any kind of energy, like electricity, water, gas or heat are supported. 

COSEM  (Companion  Specification  for  Energy  Metering)  sets  the  rules,  based  on  existing  standards, 
for data exchange with energy meters. It is designed for use with DLMS but can also be applied to 
other protocols. COSEM achieves this by using object modelling techniques to model all functions of 
the meter, without making any assumptions about which functions need to be supported, how those 
functions  are  implemented  and  how  the  data  are  transported.  The  formal  specification  of  COSEM 

16 www.dlms.org  

Digital 
Single 
Market 

 
 
 
 
 
 
 
 
                                                            
interface  classes  forms  a  major  part  of  COSEM.  To  process  and  manage  the  information  it  is 
necessary  to  uniquely  identify  all  data  items  in  a  manufacturer-independent  way.  Therefore,  the 
definition of OBIS (Object Identification System) is an essential part of COSEM. OBIS is standardized 
as  IEC  62056-6-1,  which  specifies  the  overall  structure  of  the  Object  Identification  System  and  the 
mapping  of  all  commonly  used  data  items  in  metering  equipment  to  their  identification  codes. 
COSEM is standardized as IEC 62056-6-2, which specifies a model of a meter as it is seen through its 
communication  interface(s).  Generic  building  blocks  are  defined  using  object-oriented  methods,  in 
the form of interface classes to model meters from simple up to very complex functionality. 

Description of the semantic coverage and main data elements 
A COSEM Physical device contains COSEM Logical Device(s) and must contain a Management Logical 
Device  (mandatory). A Logical device  must  have a  Logical Device Name (LDN), and  contains  two or 
more  objects  (Associations  objects  and  Application  objects),  but  also  holding  parameters  and 
measurement  values.  The  naming  system  is  based  on  OBIS,  the  Object  Identification  System:  each 
logical name is an OBIS code. There are OBIS values groups (A,B,C,D,E,F) and, for example, the group 
A specifies the media (energy type) to which the metering is related, and has the following values: 

  0: Abstract Object 
  1: Electrical Related Object 
  4: Heat Cost Allocator Related Object 
  5: Cooling Related Object 
  6: Heat Related Object 
  7: Gas Related Object 
  8: Cold Water Related Object 
  9: Hot Water Related Object 

In particular, Electrical Related Objects (A= 1) include definitions of electricity related concepts such 
as  active  power,  reactive  power  and  apparent  power.  Heat  Cost  Allocator  Related  Object  (A=4)  or 
Cooling  Related  Object  (A=5)  include  definitions  such  as  Radiator  surface  temperature,  Heating 
medium  temperature,  Flow  (forward)  temperature,  Return  temperature,  Room  temperature.  Gas 
Related Objects (A= 1) include definitions of gas related concepts such as Forward undisturbed meter 
volume,  Forward  disturbed  meter  volume,  Forward  absolute  meter  volume,  Reverse  undisturbed 
meter  volume,  Reverse  disturbed  meter  volume,  Reverse  absolute  meter  volume,  Forward 
undisturbed  converter  volume,  Forward  undisturbed  logger  volume,  Forward  undisturbed  Energy 
and so forth. Water related definitions (A= 8 or A=9) include concepts such as Accumulated volume, 
Flow rate and Forward temperature. 

Interface covered in the end-to-end DSF flow 
H2, H1 (see Figure 3-1). 

3.3.2.9 

KNX specification (CENELEC EN 50090) 

Standard Acronym and Full Name 
KNX standard for home and building control. 

Issuing Organisation/ Technical Committee/ Industry Alliance 

Digital 
Single 
Market 

 
 
 
 
 
 
KNX  Association17  is  a  non-profit-oriented  group  of  companies  active  in  many  fields  of  home  and 
building control that counts around 370 members. As common goal, these companies promote the 
development  of  building  installation  systems  and  KNX  as  a  worldwide  specification  for  home  and 
building  control,  offering  more  than  7.000  KNX  certified  product  groups  in  their  catalogues,  from 
different  application  domains.  Worldwide,  KNX  Association  has  partnership  agreements  with  more 
than  44.000  installer  companies  in  128  countries.  KNX  Association  is  the  creator  and  owner  of  the 
KNX specification, resulting from the knowledge and experience also of the predecessor technologies 
to KNX, i.e. the European Installation Bus (EIB), the European Home System (EHS) and BatiBUS. The 
KNX  specification  is  published  as  an  European  standard  by  CENELEC,  TC  205  Home  and  Building 
Electronic Systems (HBES) (see Section 3.3.1).  

Most relevant URLs, and other precise references 
The KNX specifications, including the “KNX Handbook for Home and Building Control” (fifth edition) 
are available for free at https://my.knx.org/en/shop/knx-specifications after creating an account and 
going to the purchase process to accept the license terms. The purchase itself is provided for 0 euro. 
The Chapter “KNX System Specifications Interworking Datapoint Types, version 01.08.02” is the part 
of the KNX specification v2.1 that defines the KNX Datapoint Types for Interworking.   

KNX is approved as: 

  European Standard (CENELEC EN 50090 and CEN EN 13321-1): 

o  CENELEC  EN  50090  “Home  and  Building  Electronic  Systems  (HBES)  -  Part  1: 
Standardization  structure”  by  CLC/TC  205  is  a  published  standard  available  at 
https://www.cenelec.eu/dyn/www/f?p=104:110:865087283504901::::FSP_ORG_ID,F
SP_PROJECT,FSP_LANG_ID:1258281,55668,25.  The  download  requires  credentials. 
The standard can be purchased from CENELEC's National Committees and Affiliates 
for a fee. 

o  CEN  EN  13321-1:2012  “Open  data  communication  in  building  automation,  controls 
and  building  management  -  Home  and  building  electronic  system  -  Part  1:  Product 
and  system  requirements”  by  CEN/TC  247  is  a  published  standard  available  at 
https://standards.cen.eu/dyn/www/f?p=204:110:0::::FSP_PROJECT,FSP_ORG_ID:360
19,6228&cs=1E7F5F12CB0D6E56F4BC6A9AAF5FC9DC9.  The  download 
requires 
credentials.  The  standard  can  be  purchased  from  CEN  National  Standardization 
Bodies (NSBs) for a fee. 
International Standard (ISO/IEC 14543-3)  

 

o 

is 

(HES) 
ISO/IEC  14543-3  “Information  technology 
architecture” 
at  
available, 
https://webstore.iec.ch/searchform&q=ISO/IEC%2014543-3.  The  ISO/IEC  14543-3 
standards can be purchased from the IEC webstore at https://webstore.iec.ch/ or the 
ISO webstore at https://www.iso.org/store.html.  

-  Home  electronic  system 
free, 

publicly 

not 

but 

for 

Overall description 
The KNX standard is designed for the control of applications in industrial, commercial and residential 
buildings worldwide, ranging from lighting and shutter control to various security systems, heating, 

17 www.knx.org  

Digital 
Single 
Market 

 
 
 
 
 
                                                            
ventilation, air conditioning, monitoring, alarming, water control, energy management, metering as 
well as household appliances, audio and lots more. It can be used in new as well as in existing home 
and  buildings.  The  Engineering  Tool  Software  (ETS)  is  a  manufacturer  independent  configuration 
software  tool  by  KNX  Association  to  design  and  configure  intelligent  home  and  building  control 
installations  with  the  KNX  system.  Recent  efforts  at  KNX  aim  at  investigating  the  benefits  of 
associating  a  KNX  IoT  ontology  to  the  model  underlying  the  ETS  tool  and  leverage  semantic 
technologies, as enabler to add semantic information for advanced functional queries without pre-
knowledge  on  the  devices  implementing  the  actual  functions.  The  KNX  IoT  ontology  is  available  at   
https://knxiot.org  (access to the KNX ontology requires credentials that can be obtained contacting 
the KNX association). 

Description of the semantic coverage and main data elements 
KNX  covers  Lighting,  Blinds  &  Shutters,  Security  Systems,  Energy  Management,  Heating  Ventilation 
and Air-Conditioning (HVAC) Systems, Monitoring Systems, Remote Control, Metering, Audio/Video 
Controls, and White Goods. The current KNX specifications define devices that can be configured at 
design-time  using  the  ETS  set  up  tool.  At  run-time,  KNX  is  a  data  driven  standard  that  defines 
commands.  The  parameters  in  those  commands  are  called  Datapoints.  There  are  several  types  of 
Datapoints, namely Datapoint Types for common use, Datapoint Types for HVAC, Datapoint Types for 
Load Management, Datapoint Types for Lighting, Datapoint Types for Systems. Combinations of data 
point  types  into  a  device  are  called  Functional  Blocks.  Examples  of  functional  blocks  are  Dimmer 
Actuator Basic and Sunblind Actuator Basic: 

  The DimmerActuatorBasic functional block combines the DPT_ControlDimming, DPT_Scaling 
and DPT_Switch  data point types.  This  functional block can be in one of  the 3 states “On”, 
“Off”,  or  “Dimming”,  which  are  defined  under  the  DimmingActuatorBasicState  class.    The 
change from one state to another is triggered by the so-called Events with one of the values 
listed under the  DimmingActuatorBasicEvent class.  

  The SunblindActuatorBasic functional  block combines the  DPT_Step and DPT_UpDown data 
point  types.  This  functional  block  can  be  in  one  of  the  4  states  “Stopped”,  “InMotion”,  or 
“StepUp”,  “StepDown”,  which  are  defined  under  the  SunblindActuatorBasicState  class.  The 
change from one state to another is triggered by events with one of the values listed under 
the SunblindActuatorBasicEvent class. 

Interface covered in the end-to-end DSF flow 
S2, S1 (see Figure 3-1). 

3.3.2.10 

oneM2M TS 0012 Base Ontology 

Standard Acronym and Full Name 
oneM2M TS 0012 “Base Ontology” and TS 0030 “Ontology based Interworking” 

Issuing Organisation/ Technical Committee/ Industry Alliance 
oneM2M (see Section 3.3.1). 

Most relevant URLs, and other precise references 

Digital 
Single 
Market 

 
 
 
 
 
 
 
The  latest  versions  of  the  Base  Ontology  specification,  TS  0012  Release  3  “Base  Ontology”  and  TS 
0030 
from 
http://onem2m.org/technical/published-drafts.  The  OWL  representation  of  the  oneM2M  base 
ontology can be found at https://git.onem2m.org/MAS/BaseOntology.  

Interworking", 

downloaded 

"Ontology 

based 

can 

be 

Overall description 
oneM2M  specifies  an  interoperable  framework  for  middleware  functionality  that  can  be  virtually 
used for any M2M/IoT application, independently from the underlying communication networks.  
The semantics of such M2M/IoT application layer (devices, messages, data model) can be described 
with an ontology in a formal representation (e.g. OWL format). oneM2M represents entities in terms 
of data resources, which are handled by applications and the functions of the oneM2M system (see 
oneM2M  TS-0001  "Functional  Architecture"  in  Section  3.3.3).  Therefore,  entities  of  the  application 
layer,  described  in  the  application  layer  ontology,  need  to  be  represented  as  resources  in  the 
oneM2M  system.  The  oneM2M  Base  Ontology  is  an  'upper'  ontology  that  facilitates  that  other, 
specialized,  'lower'  application  layer  ontologies  can  be  mapped  into  oneM2M  resources.  TS  0012 
specifies the oneM2M Base Ontology. TS 0030 describes the mapping into oneM2M resources. The 
design  concept  outlined  above,  using  ontologies  to  describe  the  application  layer  together  with  a 
specified mapping into resources of the global oneM2M standard, enables semantic interoperability 
between heterogeneous applications and interworking with existing non-oneM2M technologies.  

Description of the semantic coverage and main data elements 
The  oneM2M  Base  Ontology  has  been  designed  with  the  intent  to  provide  a  minimal  number  of 
concepts,  relations  and  restrictions  that  are  necessary  for  semantic  discovery  of  entities  in  the 
oneM2M  System.  The  Base  Ontology  contains  Classes  and  Properties  (i.e.,  the  schema),  but  not 
instances  (i.e.,  the  data),  since  it  is  meant  to  provide  a  semantic  description  for  data  handled  in 
oneM2M.  Instantiation  of  the  data  is  done  via  oneM2M  resources.  The  approach  is  that  given  a 
semantic  description  of  instances  according  to  the  oneM2M  Base  Ontology,  a  structure  for  a 
oneM2M  resource  can  be  automatically  created  as  follows:  specified  oneM2M  resources  (e.g.,  a 
oneM2M Application Entity resource) are created for representing devices (e.g., a washing machine). 
So-called flexContainers are used for storing dynamic data, e.g. the status of the washing machine. 
Other,  more  static  aspects  (e.g.,  the  manufacturer)  are  stored  in  special  Semantic  Descriptor 
resources  that  can  be  attached  to  several  types  of  oneM2M  resources  (e.g.,  a  semantic  descriptor 
resource  attached  to  the  oneM2M  resource  representing  a  device  would  contain  semantic 
information,  such  as  the  manufacturer).  Such  a  semantic  descriptor  resource  also  contains 
information concerning the relation to other resources, e.g. operations that can be executed. 

The oneM2M Base ontology represents the following classes: 

  A Thing in oneM2M (class: Thing) is an entity that can be identified in the oneM2M System. 
E.g.,  a  room  that  is  modelled  in  oneM2M  would  be  a  Thing  that  could  have  a  room-
temperature as a Thing Property (via hasThingProperty) and could have a hasThingRelation 
"isAdjacentTo" to another "room" Thing; 

  Thing  Property,  denotes  a  property  of  a  Thing.  E.g.,  the  indoor  temperature  of  the  room 
could be a Value of a Thing "room", or the manufacturer could be a ThingProperty of a Thing 
"car"; 

Digital 
Single 
Market 

 
 
 
 
 
  Device, which is a Thing (a sub-class of class:Thing) that is able to interact electronically with 
its environment. E.g., a "lightswitch" would be a device, a combined fridge/freezer would be 
a device that consists of a sub-device fridge and a sub-device freezer; 

o  An  Interworked  Device  describes  a  Device  which  is  not  a  oneM2M  Device  and  can 

only be accessed from the oneM2M System through an interworking proxy; 
  Function,  which  represents  the  functionality  necessary  to  accomplish  the  task  for  which  a 

Device is designed; 

o  Controlling  Function,  which  is  a  sub-class  of  Function  that  only  controls/influences 

real world Aspects that the functionality relates to; 

o  Measuring Function, which is a sub-class of Function that only measures/senses real 

world Aspects that the functionality relates to; 

  Command, which denotes an action that can be performed to support the Function; 

  Service,  which  is  a  representation  of  a  Function  to  a  network  that  makes  the  Function 

 

discoverable, registerable, remotely controllable in the network; 
Input  Data  Point,  which  is  a  Variable  of  a  Service  that  is  set  by  a  RESTful  Device  in  its 
environment and the Device reads out; 

  Output  Data  Point,  which  is  a  Variable  of  a  Service  that  is  set  by  a  RESTful  Device  in  its 

environment and that provides state information about the Service. 

  Operation, which is the means of a Service to communicate in a procedure-type manner over 
the network (i.e. transmit data to/from other devices). An Operation is a representation of a 
Command to a network; 

o  Operation Input, which describes the type of input of an Operation to a service of the 

device; 

o  Operation Output, which describes the type of output of an Operation from a service 

of the device. 

Interface covered in the end-to-end DSF flow 
S1, G3 (see Figure 3-1). 

3.3.3  Non-selected standards and industry initiatives 
The following additional standards and industry initiatives are also relevant in the scope of this study, 
but less suitable for our data elements alignment (see Section 3.4 for rationale of not inclusion in the 
short-list):  

  CEN EN 13757-1 
  CENELEC EN 50491-12 
  EFI  
  ETSI TR 103 411 (SAREF Extension Investigation) 
 
 
  oneM2M TS 0001 (Functional Architecture) 
  OpenADR 
  SPINE specification  

IEC TR 62746-2 
IEC TS 62913-2-3 

Digital 
Single 
Market 

 
 
 
 
3.3.3.1 

CEN EN 13757-1 

Standard Acronym and Full Name 
CEN EN 13757 “Communication systems for meters” Parts 1 to 6: 

  CEN EN 13757-1 “Communication systems for meters - Part 1: Data exchange”. 

Issuing Organisation/ Technical Committee/ Industry Alliance 
CEN, the European Committee for Standardization, TC 294 Communication  systems for meters (see 
Section 3.3.1).  

Most relevant URLs, and other precise references 
The EN 13757 Communication systems for meters, parts 1 and 2, are publicly available from the TC 
294 Work Programme at :   

  The 

EN 

exchange 
https://standards.cen.eu/dyn/www/f?p=204:110:0::::FSP_PROJECT:34339&cs=1F7CC9409E1
B873EB55054CACB08516CF.  

13757-1:2014 

Data 

Part 

1: 

  The 

EN 

13757-2:2004 

layer 
https://standards.cen.eu/dyn/www/f?p=204:110:0::::FSP_PROJECT,FSP_ORG_ID:20602,6275
&cs=162C0F529CCE8C55EDCB976C7A738EF82  

Physical 

Part 

and 

link 

2: 

The  download  requires  credentials.  The  standard  can  be  purchased  from  CEN's  National 
Standardization Bodies (NSBs) for a fee.  

Overall description 
The EN 13757 standard on communication systems for meters comprises 6 parts, of which Part 1 is 
especially  relevant  for  extracting  data  elements  and  therefore  for  our  state  of  standardization 
analysis. The EN 13757-1:2014 standard specifies data exchange and communications for meters and 
remote reading of meters in a generic way. It establishes a protocol specification for the Application 
Layer for meters and establishes several protocols for meter communications which may be applied 
depending  on  the  application  being  fulfilled.  Note  that  Electricity  meters  are  not  covered  by  this 
standard, as the standardization of remote readout of electricity meters is a task for CENELEC. The 
EN 13757-2:2004 standard covers the physical and link layer parameters of baseband communication 
over  twisted  pair  (M  Bus)  for  meter  communication  systems.  It  is  especially  applicable  to  heat 
meters,  heat  cost  allocators,  water  meters  and  gas  meters.  Note  that  it  is  usable  also  for  other 
meters  (like  electricity  meters)  and  for  sensors  and  actuators.  For  generic  descriptions  concerning 
communication systems for meters and remote reading of meters, see EN 13757-1. The IEC 62056-7-
3 standard, also known as DLMS UA Green Book, specifies a DLMS/COSEM M-Bus profile that allows 
running DLMS/COSEM applications over wired or wireless M-Bus.  

Description of the semantic coverage and main data elements 
The  EN  13757-1  standard  does  not  cover  electricity  meters  and  it  references  DLSM/COSEM  for 
generic  concepts  that  are  related  to  meters  and  remote  reading  of  meters.  The  IEC  62056-7-3 
standard contains a normative Annex with Mapping from M-Bus (VIF/DIF) towards COSEM identifiers 
(OBIS) for core meter data elements. Therefore, we refer the reader to IEC 62056 COSEM in Section 
3.3.2 for the core meter data elements that are also contained in EN 13757-1.   

Interface covered in the end-to-end DSF flow 

Digital 
Single 
Market 

 
 
 
 
 
 
 
H2, H1 (see Figure 3-1). 

3.3.3.2 

CENELEC EN 50491-12 

Standard Acronym and Full Name 
CENELEC  prEN  50491-12  “Smart  grid  -  Application  specification  -  Interface  and  framework  for 
customer”  is  part  of  the  EN  50491  series  “General  requirements  for  Home  and  Building  Electronic 
Systems (HBES) and Building Automation and Control Systems (BACS)”.  The upcoming standard EN 
50491-12 will comprise the following parts: 

  prEN 50491-12-1 Part 1: Interface between the CEM and Home/Building Resource manager– 

General Requirements and Architecture; 

  prEN  50491-12-2  Part  2:  Interface  between  the  Home/Building  CEM  and  Resource 

manager(s)- Data model and messaging; 

  prEN 50491-12-3 Part 3: Home/Building Customer Energy Manager (CEM); 
  Part 12-4: Resource manager. 

Issuing Organisation/ Technical Committee/ Industry Alliance 
CENELEC,  European  Committee  for  Electrotechnical  Standardization,  TC  205  Home  and  Building 
Electronic Systems (HBES) (see Section 3.3.1).  

Most relevant URLs, and other precise references 
The  prEN  50491-12-1  is  a  published  draft  currently  available  from  the  TC  205  Work  Programme  at 
https://www.cenelec.eu/dyn/www/f?p=104:110:115820593117301::::FSP_ORG_ID,FSP_PROJECT,FS
P_LANG_ID:1258281,63376,25.  The  download  requires  credentials.  The  standard  can  be  purchased 
from CENELEC's National Committees and Affiliates for a fee. The prEN 50491-12-1 draft is currently 
in the ‘Enquiry stage’ status and its Date of Publication (DOP) is estimated for 2019-10-04.  

Overall description 
Today renewable energy is not always available to meet demand. To increase efficiency, the energy 
request  should  be  aligned  with  the  available  energy  supply.  To  reach  this  goal,  communication 
between the various equipment and systems of the stakeholders within the energy field is necessary. 
This  grid,  exchanging  information  and  energy  between  producers,  consumers,  distributors  and 
metering is known as the “Smart Grid”. The 50491-12 series describes aspects of this smart grid that 
relate  specifically  to  home  and  building  electronic  systems  and  Building  Automation  and  Control 
Systems (BACS) part of a smart grid premises side system, including the common interface between 
equipment in the premises and the smart grid. 

Description of the semantic coverage and main data elements 
The draft prEN 50491-12-1 applies to all Home and Building Electronic Systems (HBES) and Building 
Automation  Control  Systems  (BACS)  and  specifies  the  general  requirements  and  architecture  of  an 
application  layer  interface  between  the  Customer  Energy  Manager  (CEM)  and  Smart  Devices  (SD) 
operating  within  the  smart  grid  premises  side  system  (i.e.  home  or  building,  but  not  industrial 
premises).  The  semantic  coverage  further  includes  concepts  and  components  such  as  Customer 
Energy Manager System (CEMS), Energy Management Gateway (EMG), Head End System (HES), Local 
Network Access Point (LNAP), Meter Data Management (MDM), Resource Manager, Neighborhood 

Digital 
Single 
Market 

 
 
 
 
 
 
Network Access Point (NNAP), Premises, Smart Appliances, Smart Grid Connection Point (SGCP) and 
Smart Meter Gateway (SMG). 

Interface covered in the end-to-end DSF flow 
S2 (see Figure 3-1). 

3.3.3.3 

EFI (input to CENELEC EN 50491-12-2) 

Standard Acronym and Full Name 
Energy Flexibility Interface (EFI) 

Issuing Organisation/ Technical Committee/ Industry Alliance 
The Flexiblepower Alliance Network (FAN)18 is an alliance of companies and institutions that jointly 
develop  and  manage  a  number  of  solutions  (i.e.,  specifications,  software  platforms  and  underlying 
technology).  The  Flexiblepower  Alliance  Network19  contributes  to  a  renewable  energy  future  by 
promoting open-source standards for flexible energy demand, matching the variations in renewable 
energy,  paving  the  way  for  a  fully  renewable  energy  future.  Solutions  offered  by  the  alliance  are 
Open  Source,  all  interested  parties  are  free  to  use  FAN  international  specifications.  Among  these 
solutions,  the  Energy  Flexibility  Interface  (EFI)20  is  a  communications  protocol  to  control  multiple 
types  of  smart  appliances  (dish  washers,  heating,  air  conditioning,  solar  panels,  car  charging)  and 
signal the smart grid its energy flexibility.  

EFI is currently an input to the TC205 WG18 for the upcoming CENELEC prEN 50491-12-2 “Smart grid 
- Application specification - Interface and framework for customer. Part 12-2: Interface between the 
Home/Building  CEM  and  Resource  manager(s)  -  Data  model  and  messaging”  (see  CENELEC  prEN 
50491-12 description in Section 3.3.3 for details). 

Most relevant URLs, and other precise references 
The 
https://github.com/flexiblepower/efi under an Apache License version 2.0 and provides: 

latest  specification  of  the  FAN  Energy  Flexibility 

Interface  (EFI  2.0) 

is  available  at 

  An XSD file that specifies the EFI schema  
  Examples of data instances in XML that are compliant with the EFI schema in XSD 

Overall description 
The underlying assumption is that manufacturers that supports EFI in their products will be able to 
communicate  with  all  Smart  Grid  technologies  (such  as  Powermatcher,  OpenADR,  Triana)  and 
developers  of  new  Smart  Grid  technologies  that  support  EFI  will  enable  communication  of  their 
solution  with  other  smart  devices  that  support  EFI.  An  important  difference  compared  to  other 
protocols is that EFI does not model a smart device, but only the available energy flexibility and the 
way it is utilized by the Smart Grid technology. By focusing only on energy flexibility, devices specific 
details and functions for other purposes than energy management can be omitted, interoperability is 
guaranteed and complexity is greatly reduced.   

18 http://flexible-energy.eu/  
19 Current partners of the alliance include Alliander (https://www.alliander.com/en), Dutch Heat Pump Association (http://dhpa-
online.nl/) and Stedin (https://www.stedin.net/).    
20 http://flexible-energy.eu/efi/  

Digital 
Single 
Market 

 
 
 
 
 
 
                                                            
 
Description of the semantic coverage and main data elements 
The semantic coverage of FAN EFI consists of the following main concepts: 

  A  Resource  represents  a  functional  (hardware)  component  that  consumes,  produces, 
releases,  or  converts  electricity  or  physical  substances  and  that  has  some  flexibility  in  its 
energy  usage  and  can  therefore  be  energy-managed.  Resources  represent  devices  within  a 
household  or  a  building  that  can  provide  flexibility  regarding  consumption,  storage  and 
production of energy;  

  Device manager, or resource manager, describes the energy flexibility of a device in a generic 
and standardized way. A CEM is only interested in exploiting energetic flexibility and not in 
the specifics of a washing machine, for instance. The energetic flexibility is expressed in the 
following four energy flexibility categories that cover most appliances:  
o  Shiftable resources are resources that can shift the generation or usage of energy over a 
specific period. Examples are washing machines with a possibility to postpone the start 
time.  Parameters  in  the  flexibility  information  of  a  shiftable  resource  are  an  energy 
profile  and  a  period  over  which  the  start  moment  can  be  shifted.  With  the  shiftable 
energy  flexibility  category  it  is  also  possible  to  send  independently  schedulable  sub-
profiles,  and  to  provide  multiple  alternative  energy  profiles  from  which  a  CEM  can 
choose; 

o  Storage resources are resources that can temporarily consume (or produce) more energy 
so they will use (or generate) less energy at a later moment in time. In most cases these 
are  thermic  buffers  such  as  heating  devices  or  refrigerators,  but  can  also  be  storage 
devices  like  electric  vehicles  or  batteries.  Examples  of  parameters  for  the  storage 
category  are:  total  buffer  capacity,  filling,  minimal  run  times  and  cooldown  times, 
leakage  functions,  usage  forecasts  and  targets  for  charging  or  discharging  the  Storage 
resource; 

o 

o  Adjustable resources are resources that are resources that can be controlled to produce 
or  consume  energy,  and  don’t  have  any  storage  constraints.  Minimal  run  times  and 
cooldown times can be described. A typical example would be a diesel generator; 
Inflexible  resources  are  type  of  Resources  whose  energy  behavior  cannot  be  controlled 
(e.g. solar panels, TV, computers, etc.). For this resources only a prediction can be made 
for the expected consumption or production of energy. These predictions can be used in 
the  rest  of  the  framework  to  make  decisions  on  energy  control.  This  category  also 
supports curtailment.  

A  CEM  receives  the  flexibility  information  and  decides  how  to  exploit  the  energetic  flexibility.  As  a 
response to the flexibility inform, the CEM will send an instruction which contains the energy profile 
that  a  resource  must  follow.  An  instruction  should  always  respect  the  constraints  that  were 
expressed in the flexibility information, although it is possible to  violate flexibility constrains in the 
case of grid emergencies. 

Interface covered in the end-to-end DSF flow 
S2 (see Figure 3-1). 

Digital 
Single 
Market 

 
 
 
 
 
3.3.3.4 

ETSI TR 103 411 (SAREF Extension Investigation) 

Standard Acronym and Full Name 
ETSI TR 103 411 “SmartM2M; Smart Appliances; SAREF extension investigation”. 

Issuing Organisation/ Technical Committee/ Industry Alliance 
ETSI,  European  Telecommunications  Standards 
communications (SmartM2M) (see Section 3.3.1). 

Institute,  TC  Smart  Machine-to-Machine 

Most relevant URLs, and other precise references 
The  SAREF  extension  investigation  TR  103  411  V1.1.1  (2017-02)  can  be  downloaded  for  free  from 
http://www.etsi.org/deliver/etsi_ts/103200_103299/103264/02.01.01_60/ts_103264v020101p.pdf  

The TR 103 411 technical report further contains an example of  how to instantiate a power profile 
using the SAREF4ENER extension of SAREF (see Section 3.3.2 for details on SAREF4ENER). The Turtle21 
code 
from 
http://ontology.tno.nl/examples/saref4ener/heatingsystem.ttl. 

downloaded 

example 

this 

can 

for 

be 

Overall description 
Following the first SAREF study promoted by the European Commission (SMART 2013/0077), ETSI TC 
SmartM2M requested in 2016 a Specialist Task Force (STF) to provide input on the management of 
SAREF, identify possible SAREF extensions in specific domains and  create these extensions. STF 513 
was  therefore  established  with  the  goal  to  develop  3  extensions  for  SAREF  in  the  Energy, 
Environment and Building domains. The TR 103 411 “SmartM2M; Smart Appliances; SAREF extension 
investigation”  describes  the  use  cases  covered  by  the  three  extensions  SAREF4ENER,  SAREF4ENVI 
and SAREF4BLDG, and the requirements that were used to build these extensions. TR 103 411 further 
proposes a strategy for the extension and maintenance of SAREF and its extensions. Furthermore, it 
provides examples of data based on SAREF and its extensions. 

Description of the semantic coverage and main data elements 
The  TR  103  411  technical  report  describes,  among  others,  the  use  cases  covered  by  the  extension 
SAREF4ENER for the energy domain, which are the following:    

  Use  case  1:  configuration  of  devices  that  want  to  connect  to  each  other  in  the  home 
network,  for  example,  to  register  a  new  dishwasher  to  the  list  of  devices  managed  by  the 
CEM; 

  Use case 2: smart energy management/ (re-)scheduling of appliances in certain modes and 
preferred  times  using  power  profiles  to  optimize  energy  efficiency  and  accommodate  the 
customer's preferences; 

  Use case 3: monitoring and control of the start and status of the appliances;  
  Use  case  4:  reaction  to  special  requests  from  the  Smart  Grid;  for  example,  incentives  to 
consume  depending  on  current  energy  availability,  or  emergency  situations  that  require 
temporary reduction of the power consumption. 

21 Turtle (file extension “.ttl”) is a serialization for ontologies and data expressed in RDF/OWL that offers a 
compact and easy to understand syntax also for humans. Turtle files can be opened as text files using any text 
editor such as Notepad, or can be inspected using ontology editors such as Protégé or TopBraid Composer.  

Digital 
Single 
Market 

 
 
 
 
 
 
 
 
                                                            
These use cases are associated with user stories such as the following: 

  User wants to do basic settings of his/her devices; 
  User wants to know when the washing machine has finished working; 
  User wants the washing done by 5:00 p.m. with least electrical power costs; 
  User likes to limit his/her own energy consumption up to a defined limit; 
  User allows the CEM to reduce the energy consumption of his/her freezer in a defined range 

for a specific time, if the grid recognizes (severe) stability issues; 

  Grid related emergency situations (blackout prevention). 

Concerning data elements, the TR 103 411 technical report includes an example of how to instantiate 
a Power Profile used by a heating system with hot water tank to communicate its energy flexibility to 
the  CEM  according  to  the  consumer's  preferences  and  needs.  The  power  profile  is  used  by  the 
heating system device to expose the power sequences that are potentially relevant for the CEM, for 
example,  regarding  its  expected  energy  consumption  for  a  certain  day.  In  particular,  the  power 
profile  in  the  example  consists  of  two  groups  with  alternative  plans  (each  group  modelled  as  an 
AlternativesGroup class) that do not overlap in time and allow to model consecutive (and also rather 
independent)  periods  of  action:  1)  one  group  of  alternatives  for  a  task  in  the  morning,  and  2)  a 
second group of alternatives for another task in the afternoon. Within one group, there can be one 
or  more  plans  (or  power  sequences)  that  are  alternatives  to  each  other,  i.e.,  at  most  one  of  these 
plans/power sequences can be finally executed. For example, in the afternoon alternative group, the 
heating  system  can  offer  the  two  following  alternative  plans  to  charge  the  hot  water  tank:  2.a)  a 
"cheapest" plan in which the CEM should try to minimize the user's energy bill and permits the CEM 
to shift the start between e.g. 2:45 p.m. and 5:00 p.m.; and 2.b) a "greenest" plan in which the CEM 
should try to  optimize the  configuration  towards  the  maximum  availability  of  renewable  energy (it 
can even announce  the user's  preference  for  "green  energy").  In other  words,  the  CEM  can  take  a 
choice for the "cheap" or "green" plan for the afternoon. These plans may have further options with 
regards  to  their  flexibility.  For  example,  one  of  the  plans  may  offer  that  the  CEM  can  pause  a 
sequence  (as  long  as  the  sequence  completes  before  the  latest  time  set  by  the  user).  Finally,  a 
plan/power sequence consists of one or more slots that represent different phases of consumption 
(or production) and their values. The power sequences of the heating system example have a single 
slot each. However, for other devices such as washing machines, a power sequence may have various 
slots for the different phases of washing, such as heating the water, washing and rinsing. 

Interface covered in the end-to-end DSF flow 
S2, S1 (see Figure 3-1). 

3.3.3.5 

IEC TR 62746-2 

Standard Acronym and Full Name 
IEC  TR  62746-2  “Systems  interface  between  customer  energy  management  system  and  the  power 
management system - Part 2: Use cases and requirements”. 

Issuing Organisation/ Technical Committee/ Industry Alliance 
IEC,  International  Electrotechnical  Commission,  TC57  -  Power  systems  management  and  associated 
information exchange, WG 21 - Interfaces and protocol profiles relevant to systems connected to the 
electrical grid (see Section 3.3.1).  

Digital 
Single 
Market 

 
 
 
 
 
TR 

Most relevant URLs, and other precise references 
IEC 
at 
published 
https://webstore.iec.ch/publication/22279.  This  standard  is  not  available  for  free,  but  it  can  be 
purchased from IEC. 

62746-2:2015(EN) 

document 

currently 

available 

is 

a 

Overall description 
IEC TR 62746-2 describes the main pillars of interoperability to assist different Technical Committees 
in defining their interfaces and messages covering the whole chain between a smart grid and smart 
home/building/industrial  (H/B/I)  area.  The  main  topics  covered  by  this  technical  report  are: 
architecture  model  from  a  logical  point  of  view;  set  of  user  stories  describing  several  situations 
related to energy flexibility and demand side management; set of use cases based on the user stories 
and  architecture;  details  of  the  communication;  identified  in  the  use  cases,  by  describing  the 
requirements for messages and information to be exchanged. 

Description of the semantic coverage and main data elements 
As  discussed  in  Section  2,  the  IEC  TR  62746-2  document  covers  several  use  cases  from  which  we 
could identify the following data elements: 

  Use case 2, Flexible start of Smart Device (SD) 

o  Control parameters, e.g. profile selection 
o  Preferred time slot of operation per SD 
o  Flex start enabled 
o  Energy consumption 
o  Energy Profile 
o  Start time/ time slot of operation 
o  New tariff information 
o  Recalculated start time / time slot 
o  Operation commands 

  Use case 3 Response of Smart Home to Emergency 

o  Emergency signal 
o  Emergency load command 

  Use  case  4,  Control  of  non-smart  Device  by  CEM,  based  on  pre-set  tariff  threshold  (set  by 

user) and actual tariff 

o  Tariff threshold 
o  Real Time Tariff 
o  operation commands (increase or decrease power and turn off/on) 

  Use case 5, Direct Load Control of Smart Device via CEM 

Id of participating devices 

o 
o  Power thresholds 
o  Load management signal 
o  Load adjustment command 
o  Feedback about adjustment 
o  Expected change in consumption 

  Use case 6, Demand-supply adjustment by cooperation between supplier and customer 

o  Price information of electrical energy based on time of use (TOU) 

Digital 
Single 
Market 

 
 
 
 
 
o  Planned load profile (expected consumption in time) 
  Use case 7, Exchanging information on (partial) consumption 

o  Actual Individual Appliances (= partial) consumption/generation 
o  Forecasted partial consumption/generation 
o  Actual total house consumption 
o  Forecasted total house consumption 

  Use case 8, External Actor Retrieves status of smart devices 

o  Device Status Request 
o  Device Status 
o  Status is displayed to consumer 

  Use  case  9,  CEM  requests  time  from  Smart  Meter  GW  and  Smart  Meter  GW  synchronizes 

time of CEM 

o  Actual time request 
o  Actual time 

  Use case 10, Smart Meter GW notifies actual tariff to CEM 

o  Active tariff notification 

Interface covered in the end-to-end DSF flow 
S2, S1, G3, H2, H1 (see Figure 3-1). 

3.3.3.6 

IEC TS 62913-2-3 

Standard Acronym and Full Name 
IEC TS 62913-2-3 Ed.1 “Generic Smart Grid Requirements - Part 2-3: Domains - Resources connected 
to  the  grid  related  domains,  these  include  Bulk  Generation,  Distributed  Energy  Resources,  Smart 
Home / Commercial / Industrial / DR-Customer Energy Management, and Energy Storage” 

Issuing Organisation/ Technical Committee/ Industry Alliance 
IEC,  International  Electrotechnical  Commission  TC8  -  Systems  aspects  for  electrical  energy  supply, 
WG6 SyC Smart Energy (see Section 3.3.1). 

Most relevant URLs, and other precise references 
IEC 
at 
http://www.iec.ch/dyn/www/f?p=103:38:7354931541404::::FSP_ORG_ID,FSP_APEX_PAGE,FSP_PROJ
ECT_ID:11825,23,22240. This standard is not available for free, but it can be purchased from IEC. 

62913-2-3 

available 

ED1 

TS 

is 

Overall description 
The  IEC  TS  62913-2-3  document  defines  the  Generic  Smart  Grid  Requirements  of  resources 
connected  to  the  grid  related  domains.  Chapter  4  provides  a  business  analysis  of  Smart  Home  / 
Commercial / Industrial / DR-Customer and Energy Management. It presents a list of ‘Business Use 
cases’ for Smart Homes, as well as ‘System Use Cases’. 

Description of the semantic coverage and main data elements 
As  discussed in Section 2,  the IEC  TS  62913-2-3  document  covers  several  use  cases  from  which  we 
could identify the following data elements: 

  Use case 1, Device Registration & Configuration 

Digital 
Single 
Market 

 
 
 
 
 
 
 
o  Device Identifier 
o  Device capabilities 
The original specification refers to “Smart Devices” and since this Use Cases should also 
cover CEM identifier and capabilities, we use the word “Device”.  

  Use case 2, Flexible start of Smart Device (SD) 

o  Control parameters, e.g. profile selection 
o  Preferred time slot of operation per SD 
o  Flex start enabled 
o  Energy consumption 
o  Energy Profile 
o  Start time/ time slot of operation 
o  New tariff information 
o  Recalculated start time / time slot 
o  Operation commands 

  Use case 3 Response of Smart Home to Emergency 

o  Emergency signal 
o  Emergency load command 

  Use case 5, Direct Load Control of Smart Device via CEM 

Id of participating devices 

o 
o  Power thresholds 
o  Load management signal 
o  Load adjustment command 
o  Feedback about adjustment 
o  Expected change in consumption 

  Use case 6, Demand-supply adjustment by cooperation between supplier and customer 

o  Price information of electrical energy based on time of use (TOU) 
o  Planned load profile (expected consumption in time) 

Interface covered in the end-to-end DSF flow 
S2, S1, G3, H2 (see Figure 3-1). 

3.3.3.7 

oneM2M TS 0001 (Functional Architecture) 

Standard Acronym and Full Name 
oneM2M TS 0001 Functional Architecture 

Issuing Organisation/ Technical Committee/ Industry Alliance 
oneM2M (see Section 3.3.1). 

Most relevant URLs, and other precise references 
The  latest  version  of  the  oneM2M  Functional  Architecture  specification  can  be  downloaded  from 
http://onem2m.org/technical/published-drafts. In this study we consider TS 0001 V2.10.0 Release 2 
“Functional Architecture”.  

Overall description 

Digital 
Single 
Market 

 
 
 
 
 
 
oneM2M  defines  a  Layered  Model  for  supporting  end-to-end  (E2E)  M2M  Services  that  comprises 
three layers: Application Layer, Common Services Layer and the underlying Network Services Layer. 
The  TS  0001  specification  describes  the  end-to-end  oneM2M  functional  architecture  across  this 
oneM2M Layered Model and comprises the following three main entities: 1) Application Entity (AE), 
which  is  an  entity  in  the  Application  Layer  that  implements  an  M2M  application  service  logic. 
Examples  of  the  AEs  include  an  instance  of  a  fleet  tracking  application,  a  remote  blood  sugar 
monitoring  application,  a  power  metering  application,  or  a  controlling  application;  2)  Common 
Services Entity (CSE), which represents an instantiation of a set of "common service functions" of the 
M2M  environments.  Such  service  functions  are  exposed  to  other  entities  through  reference  points 
(interfaces)  called  “Mca”  and  “Mcc”.  Another  reference  point,  called  “Mcn”,  is  used  for  accessing 
underlying  Network  Service  Entities.  Examples  of  service  functions  offered  by  CSE  include:  Data 
Management, Device Management, M2M Service Subscription Management, and Location Services; 
and  3)  Underlying  Network  Services  Entity  (NSE),  which  provides  services  from  the  underlying 
network  to  the  CSEs.  Examples  of  such  services  include  device  management,  location  services  and 
device triggering. 

Description of the semantic coverage and main data elements 
The semantic coverage of the Functional Architecture specification includes the following concepts:  

  Application  Layer:  comprises  oneM2M  Applications  and  related  business  and  operational 

logic; 

  Application  Entity:  represents  an  instantiation  of  Application  logic  for  end-to-end  M2M 

solutions; 

  Common  Services  Entity  (CSE):  represents  an  instantiation  of  a  set  of  Common  Service 
Functions  of  the  M2M  environments.  Such  service  functions  are  exposed  to  other  entities 
through reference points; 

  Common  Services  Layer:  consists  of  oneM2M  service  functions  that  enable  oneM2M 

Applications (e.g. management, discovery and policy enforcement); 

  Common Services Function (CSF): architectural construct which conceptually groups together 

several sub-functions;  

  M2M  Application:  applications  that  run  the  service  logic  and  use  M2M  Common  Services 

accessible via a set of oneM2M specified open interfaces; 

  M2M  Application  Infrastructure:  equipment  (e.g.  a  set  of  physical  servers  of  the  M2M 
Application  Service  Provider)  that  manages  data  and  executes  coordination  functions  of 
M2M Application Services; 

  M2M  Application  Service:  realized  through  the  service  logic  of  an  M2M  Application  and  is 

operated by the User or an M2M Application Service Provider; 

  M2M  Application  Service  Provider:  entity  (e.g.  a  company)  that  provides  M2M  Application 

Services to the User; 

  M2M Area Network: form of an Underlying Network that minimally provides data transport 

services among M2M Gateway(s), M2M Device(s), and Sensing&Actuation Equipment; 

  M2M  Device:  physical  equipment  with  communication  capabilities,  providing  computing 

and/or sensing and/or actuation services; 

  M2M Common Services: set of oneM2M specified functionalities that are widely applicable 
to  different  application  domains  made  available  through  the  set  of  oneM2M  specified 
interfaces; 

Digital 
Single 
Market 

 
 
 
  M2M  Gateway:  physical  equipment  that  includes,  at  minimum,  the  entities  and  APIs  of  a 

Middle Node; 

  M2M  Service:  consists  of  one  or  more  M2M  Application  Services  and  one  or  more  M2M 

Common Services; 

  M2M Service Infrastructure: physical equipment (e.g. a set of physical servers) that provides 
management  of  data  and  coordination  capabilities  for  the  M2M  Service  Provider  and 
communicates with M2M Devices; 

  M2M  Service  Provider:  entity  (e.g.  a  company)  that  provides  M2M  Common  Services  to  a 

M2M Application Service Provider or to the User; 

  Managed Entity: may be either an M2M Device, M2M Gateway, or a device in the M2M Area 

Network or the M2M Application Layer or M2M Service Layer software components; 

  Network Services Layer: provides transport, connectivity and service functions; 
  Node: logical entity that is identifiable in the oneM2M System; 
  non-oneM2M Node: node that does not contain oneM2M Entities; 
  oneM2M  System:  system  developed  by  the  oneM2M  global 

initiative  that  enables 

deployable M2M Solutions;   

  Reference  Point:  A  reference  point  consists  of  one  or  more  interfaces  of  any  kind.  The 
following  reference  points  are  supported  by  the  Common  Services  Entity  (CSE):  Mca 
Reference Point, Mcc Reference Point, Mcn Reference Point and Mcc' Reference Point; 

  Resource: uniquely addressable entity in oneM2M architecture; 
  Thing: element which is individually identifiable in the oneM2M system; 
  Virtual  Device:  logical  device  (implemented  as  software)  that  acts  similar  to  physical  M2M 
Device  and  provides  derived  data.  EXAMPLE:  Average  temperature  of  a  room,  number  of 
vehicles that passed during the last minute. 

Interface covered in the end-to-end DSF flow 
S1, G3 (see Figure 3-1). 

3.3.3.8 

OpenADR 

Standard Acronym and Full Name 
OpenADR (Automated Demand Response) Profile Specification. 

Issuing Organisation/ Technical Committee/ Industry Alliance 
The  OpenADR  Alliance  (http://www.openadr.org)  was  formed  in  2010  by  industry  stakeholders  to 
foster  the  development,  adoption  and  compliance  of  the  Open  Automated  Demand  Response 
(OpenADR) Smart Grid standard. The mission of the OpenADR Alliance is to foster the development, 
adoption, and compliance of the Open Automated Demand Response (OpenADR) standards through 
collaboration, education, training, testing and certification. 

Most relevant URLs, and other precise references 
OpenADR 2.0a Profile Specification_v1.0 
OpenADR 2.0b Profile Specification_v1.1 

Digital 
Single 
Market 

 
 
 
 
 
 
Based on the OASIS Energy Interoperation Standard, the OpenADR Alliance created several product 
profile  specifications.  The  OpenADR  2.0a  and  OpenADR  2.0b  Profile  Specifications  provide  specific 
implementation related information to build an OpenADR enabled device or system.  

The  OpenADR  2.0  Specifications  can  be  downloaded  from  http://www.openadr.org/specification 
after registration. 

Overall description 
Demand  Response  (DR)  plays  a  vital  role  in  grid  stabilization  during  hot  Summers,  easing  severely 
constrained  electrical  grids  from  coast-to-coast.  Future  energy  crises  caused  by  electricity  demand 
exceeding  system  capacity  can  be  postponed  or  even  averted  through  Demand  Response.  
Automated  Demand  Response  (ADR)  helps  system  operators  reduce  the  operating  costs  of  DR 
programs  while  increasing  DR  resource  reliability.  For  customers,  ADR  reduces  the  resources  and 
effort required to achieve successful results from these DR programs. Automation is what also makes 
it  possible  to  translate  changes  in  wholesale  markets  to  corresponding  changes  in  retail  rates, 
enabling customers to respond to DR signals in real-time to reduce demand. 
Successful  implementation  of  ADR  requires  standardization  allowing  wholesale  producers  to 
communicate with utilities and aggregators, who in turn communicate with their customers, who can 
then  reduce  demand  during  peak  periods.  Without  an  ADR  standard,  automated  DR  would  be 
difficult and costly to implement. System development, integration and installation costs could grow 
to prohibitive levels, and these proprietary and expensive assets could eventually become stranded.  
Open  Automated  Demand  Response  (OpenADR)  is  an  open  and  standardized  way  for  electricity 
providers and system operators to communicate DR signals with each other and with their customers 
using a common language over any existing IP-based communications network, such as the Internet.  
OpenADR has achieved widespread support throughout the industry. 

Description of the semantic coverage and main data elements 
The  OpenADR  2.0  profile  specification  is  a  flexible  data  model  to  facilitate  common  information 
exchange between electricity service providers, aggregators, and end users. The concept of an open 
specification is intended to allow anyone to implement the two-way signalling systems, providing the 
servers,  which  publish  information  (Virtual  Top  Nodes  or  VTNs)  to  the  automated  clients,  which 
subscribe the information (Virtual End Nodes, or VENs). This OpenADR 2.0 profile specification covers 
the signalling data models between VTN and VEN (or VTN/VEN pairs) and does include information 
related to specific DR electric reduction or shifting strategies, which are taken at the facility.  

OpenADR 2.0 supports the following services from OASIS EI Version 1.0 standard or subset thereof. 
Extensions to these services are included to meet the DR stakeholder and market requirements: 

  Registration (EiRegisterParty): Register is used to identify entities such as VEN’s and parties. 
This is necessary in advance of an actor interacting with other parties in various roles such as 
VEN, VTN, tenderer, and so forth. 

  Enrollment  (EiEnroll):  Used  to  enroll  a  Resource  for  participation  in  DR  programs.  This 
establishes a relationship between two actors as a basis for further interactions. (Planned for 
future releases) 

Digital 
Single 
Market 

 
 
 
 
 
 
  Market  Contexts  (EiMarketContext):  Used  to  discover  program  rules,  standard  reports,  etc. 
Market contexts are used to express market information that rarely changes, and thereafter 
need not be communicated with each message. (Planned for future releases) 

  Event  (EiEvent):  The  core  DR  event  functions  and  information  models  for  price  responsive 
DR. This service is used to call for performance under a transaction. The service parameters 
and  event  information  distinguish  different  types  of  events.  Event  types  include  reliability 
events, emergency events, and more – and events MAY be defined for other actions under a 
transaction. 

  Quote  or  Dynamic  Prices  (EiQuote):  EiDistributeQuote  for  distributing  complex  dynamic 
prices such as block and tier tariff communication. These are sometimes referred to as price 
signals;  such  signals  are  indications  of  a  possible  tender  price  -  they  are  not  themselves 
actionable. 

  Reporting or Feedback (EiReport): The ability to set periodic or one-time information on the 

state of a Resource (response). 

  Availability  (EiAvail):  Constraints  on  the  availability  of  Resources.  This  information  is  set  by 
the end node and indicates when an event may or may not be accepted and executed by the 
VEN with respect to a Market Context. Knowing the Availability and Opt information for its 
VENs improves the ability of the VTN to estimate response to an event or request. (Planned 
for future releases) 

  Opt or Override (EiOpt): Overrides the EiAvail; addresses short-term changes in availability to 

create and communicate Opt-in and Opt-out schedules from the VEN to the VTN. 

Interface covered in the end-to-end DSF flow 
G3 (see Figure 3-1). 

3.3.3.9 

SPINE  

Standard Acronym and Full Name 
SPINE (Smart Premises Interoperable Neutral-Message Exchange) specification.  

Issuing Organisation/ Technical Committee/ Industry Alliance 
The  SPINE specification  is  created  and maintained by  the EEBUS  initiative  in  collaboration with  the 
Energy@home  association.  Nota  that  the  SPINE  specification  is  standardized  by  TC  59  WG  7  in 
CENELEC (see Section 3.3.1) in the prEN 50631-1 specification (see CENELEC EN 50631-1 description 
in Section 3.3.2).  

EEBUS is a non-profit organization for interoperability in the area of the Internet of Things with 
a strong focus on standardisation. The EEBUS initiative focuses on domains such as smart energy, 
smart home and building, connected devices (domestic appliances, heating and air conditioning), 
connected car and, more in general, smart connectivity. Originated in Germany, the EEBUS initiative 
counts now global partnerships with various associations in Europe, Asia and the USA. EEBUS is active 
in several standardisation bodies, such as the VDE standardisation organisation DKE in Germany, and 
relevant organisations at European (CENELEC and ETSI) and international level (IEC). The benefit of 
standardisation  is  used  by  the  EEBUS  initiative  to  open  up  a  future  market  which  could  not  be 
realized through closed systems. 

Digital 
Single 
Market 

 
 
 
 
 
 
Energy@home is a non-profit organization founded in 2012 from the results of a collaborative 
project among Electrolux, Enel Distribuzione, Indesit Company and Telecom Italia. The Energy@home 
association  includes  now  various  European  members  with  the  mission  of  developing  technologies 
and  services  for  energy  efficiency  in  smart  homes,  based  on  the  interaction  between  user  devices 
and  the  energy  infrastructure.  The  goal  of  Energy@home  association  is  to  promote  products  and 
services based on the interoperability of various appliances within the household. Energy@home has 
established  a  Standardisation  Committee  to  maintain  its  technical  specifications  leveraging  on 
collaborations with other standard organisations and alliances, such as the EEBUS initiative and the 
ZigBee Alliance (Energy@home is an acknowledged contributor to the ZigBee Home Automation 1.2 
standard). 

Most relevant URLs, and other precise references 
The SPINE Specification 1.0 (2016-04-29) consists of the following documents: 
  SPINE Technical Report Introduction “Intro duction” Version 1.0.0 
  SPINE Technical Specification “Protocol Specification” Version 1.0.0 
  SPINE Technical Specification “Resource Specification” Version 1.0.0 
  SPINE_V1.0.0_XSDs 

The  SPINE  specification  can  be  downloaded  from  https://www.eebus.org/en/downloads/  after 
registration.  

Overall description 
SPINE  defines  a  neutral  layer  to  connect  different  technologies  to  build  a  smart  home/  smart  grid 
system.  SPINE  defines  messages  and  procedures  on  application  level  and  is  independent  from  the 
used transport protocol. Any technology that supports the bi-directional exchange of arbitrary data 
can  be  used  directly,  e.g.,  SmartHome  IP  (SHIP),  which  is  also  created  by  the  EEBUS  Initiative,  or 
Thread,  which  is  very  much  used  by  the  Energy@home  association.  For  other  communications 
technologies,  a  mapping  is  needed.  SPINE  covers  use  cases  concerning  control  and  monitoring  of 
smart  appliances  like  White  Goods,  HVAC  systems  and  adjacent  devices  like  batteries,  e-cars,  etc. 
with  a  focus  on  the  sectors  of  smart  energy,  smart  home  and  building,  connected  devices  and  E-
Mobility. Domains like Ambient Assisted Living (AAL), home entertainment, etc. are currently not in 
the focus  of  SPINE,  although some use  cases  from these  domains  can be  realised with the  existing 
data model. The SPINE data model evolves continuously. Hence, further domains will be added in the 
future.  The  SPINE  data  model  is  specified  in  XML  Schema  Definition  (XSD),  therefore  the  file 
extension ".xsd".  

The SPINE data model is divided into classes, functions and elements as follows: 

  Classes,  such  as  the  Measurement,  Sensing,  and  Time  Information  classes,  define  sets  of 
functions that can be used for communication. For example, the Measurement class defines 
all functions related to measurement; 
the 

  Functions  are 

that  are  used 

resources 

for  communication.  For  example, 
the 

functions 

for 

measurementListData  and  measurementConstraintsListData  are 
Measurement class; 

  Elements are function specific datapoints that represent a single piece of information, such 
as a value, a timestamp, a unit, etc. A function defines a set of elements. For example, the 

Digital 
Single 
Market 

 
 
 
 
 
 
measurementListData  element  of  the  corresponding  measurementListData  function 
contains the actual value of a measurement. 

Description of the semantic coverage and main data elements 
The SPINE data model covers Device Types, Entity Types and Feature Types/Classes, as follows: 

  Device Types (i.e., physical devices such as a “Fridge Freezer” or “Heat Pump”): Dishwasher, 
Dryer,  Environment  Sensor,  Heat  Generation  System,  Heat  Sink  System,  Heat  Storage 
System, HVAC Controller, Sub Meter, Washer. 

  Entity  Types  (i.e.,  logical  devices  such  as  a  “Freezer”  that  is  one  logical  part  of  a  physical 
device  “FridgeFreezer”):  Battery,  Compressor,  Domestic  Hot  Water  (DHW)  Circuit,  DHW 
Storage,  Dishwasher,  Dryer,  Electrical  Immersion  Heater,  Fan,  Gas  Heating  Appliance, 
Heating Buffer Storage, Heating Circuit, Heating Object, Heating Zone, Heat Pump Appliance, 
Heat  Sink  Circuit,  Heat  Source  Circuit,  Heat  Source  Unit,  HVAC  Controller,  HVAC  Room, 
Household, Instant DHW  Heater, Inverter, Oil Heating Appliance, Pump, Refrigerant Circuit, 
Smart  Energy  Appliance,  Solar  DHW  Storage,  Solar  Thermal  Circuit,  Sub  Meter  Electricity, 
Temperature Sensor, Washer. 

  Feature  Types  (i.e.,  specific  usage  of  a  function  defined  by  a  Class)  and  corresponding 
Classes: Actuator Level, Actuator Switch, Alarm, Data Tunneling, Device Classification, Device 
Diagnosis,  Direct  Control,  Electrical  Connection,  HVAC,  Load  Control,  Measurement, 
Messaging,  Network  Management,  Node  Management,  Operating  Constraints,  Power 
Sequences,  Sensing,  Setpoint,  Smart  Energy  Management  Ps,  Subscription  Management, 
Supply Condition, Task Management, Threshold, Time Information, Time Table, Version.  

Interface covered in the end-to-end DSF flow 
S2 (see Figure 3-1). 

3.4  Results  
The  objective  of  this  task  was  to  identify  a  short  list  of  standards  to  be  used  as  a  basis  to  further 
proceed with alignments  and to assess if the use  cases and data elements in  scope are sufficiently 
covered by these standards, using SAREF and SAREF4ENER as common mapping tool. 

3.4.1  Short list of standards 
The short-listed standards are used as a basis to further proceed with data alignments in the study. 
The short list is presented in the table below. 

Table 3-2: Short list of standards identified in the DSF study 

# 

2 

Reference/ Issued by 

URL 

CEN EN 16836 (TC 294) )/ ZigBee SEP2 (ZigBee Alliance) 
Communication  systems 
networking for meter data exchange  

for  meters 

-  Wireless  mesh 

https://standards.cen.eu/dyn/www/f?p=204:32:0::
::FSP_ORG_ID,FSP_LANG_ID:6275,25&cs=1A1D2A7
OR 
1837AB4AB1532B872DBD554033 
http://www.zigbee.org/about/centc294 

Digital 
Single 
Market 

 
 
 
 
 
# 

3 

5 

7 

8 

10 

11 

12 

15 

Reference/ Issued by 

URL 

CENELEC EN 50491-11 (TC 205) 
General  requirements  for  Home  and  Building  Electronic 
Systems  (HBES)  and  Building  Automation  and  Control 
Systems  (BACS)  -  Part  11:  Smart  Metering  -  Application 
Specifications - Simple External Consumer Display 

https://www.cenelec.eu/dyn/www/f?p=104:110:1
686791285416701::::FSP_ORG_ID,FSP_PROJECT,FS
P_LANG_ID:1258281,42730,25 

CENELEC prEN 50631-1 (TC59 WG7) / SPINE (EEBUS and E@h) 
Household appliances network and grid connectivity - Part 1: 
General  Requirements,  Generic  Data  Modelling  and  Neutral 
Messages 

https://www.cenelec.eu/dyn/www/f?p=104:110:1
438163728984601::::FSP_ORG_ID,FSP_PROJECT,FS
P_LANG_ID:1257245,47024,25 
OR 
https://www.eebus.org/en/downloads/ 

ETSI SAREF TS 103 264 (SmartM2M TC) 
SmartM2M;  Smart  Appliances;  Reference  Ontology  and 
oneM2M Mapping 

http://www.etsi.org/deliver/etsi_ts/103200_1032
99/103264/02.01.01_60/ts_103264v020101p.pdf  

ETSI SAREF4ENER TS 103 410-1 (SmartM2M TC) 
SmartM2M;  Smart  Appliances  Extension  to  SAREF;  Part  1: 
Energy Domain 

http://www.etsi.org/deliver/etsi_ts/103400_1034
99/10341001/01.01.01_60/ts_10341001v010101p.
pdf 

IEC 61968-9 CIM for Metering (TC 57 WG14) 
Common 
Management 

Information  Model 

(CIM)/ 

http://www.iec.ch/smartgrid/standards/  

Distribution 

IEC 61970-301 CIM Core (TC 57) 
Common information model (CIM)/Energy Management 

http://www.iec.ch/smartgrid/standards/  

IEC/ CENELEC 62056 COSEM (TC 13 WG 14) 
Electricity metering - Data exchange for meter reading, tariff 
and load control  

https://webstore.iec.ch/publication/24231 
http://dlms.com/PASSWORD/Books/Blue_Book_1
1th_edition.pdf  

OR 

CENELEC  EN  50090  for  home  building  and  control  (TC  205)/ 
KNX  specification  for  home  building  and  control  (KNX 
Association) 

https://my.knx.org/en/shop/knx-specifications 

17 

oneM2M Base Ontology TS 0012 (oneM2M) 

http://onem2m.org/technical/published-drafts 

Note that this short list is not an endorsement by DNV-GL, TNO, ESMIG or the European Commission, 
it only provides a means to further proceed with alignments and investigate a possible solution for 
interoperability  in  this  study.  Standards  that  are  not  included  in  the  short  list  can  be  used  by  the 
interested  stakeholders  to  generate  new  interoperability  solutions  using  the  alignment  approach 
proposed in Section 4.2.   

3.4.2  Non-selected standards 
Nine standards from the long list have been discarded from further proceeding with alignments, as 
they did not satisfy one or more of the Short List (SL) criteria presented in Section 3.2. Note that the 
complete state of  standardisation  for DSF  in the scope of  this  study  is  provided by  both  the short-
listed and the non-selected standards. The non-selected standards are:  

  CEN EN 13757-1 
  CENELEC EN 50491-12 
  EFI (input to CENELEC EN 50491-12-2) 
  ETSI TR 103 411 (SAREF Extension Investigation) 

Digital 
Single 
Market 

 
 
 
 
IEC TR 62746-2 
IEC TS 62913-2-3 

 
 
  oneM2M TS 0001 (Functional Architecture) 
  OpenADR 
  SPINE specification (referenced in CENELEC EN 50631-1) 

These standards and industry specifications are not considered for further data elements alignment 
in this study for the following reasons: 

  CEN EN 13757-1 references COSEM identifiers (OBIS) for core meter data elements, and IEC 
62056 COSEM was already selected to be part of our short list. Therefore, it is not necessary 
to consider also CEN EN 13757-1.  

  CENELEC  EN  50491-12-1  specifies  the  general  requirements  and  architecture  between  the 
Customer  Energy  Manager  (CEM)  and  Smart  Devices.  Therefore,  it  does  not  contain  data 
definitions that allow us to extract data elements, as required by criterion SL1 in Section 3.2. 
In  contrast,  CENELEC  EN  50491-12-2  would  be  suitable  for  data  alignments,  but  it  is  an 
ongoing  work  in  TC  205  WG18  and  there  is  no  draft  specification  that  can  be  referenced. 
Therefore it cannot be considered as input for our study. 

  EFI is one of the inputs currently used for discussion for the upcoming CENELEC EN 50491-12-
2. It is suitable for data alignments, but it is not recognised yet by any official standardization 
body nor is a de-facto widely-adopted international industry standard, therefore it cannot be 
further considered in this study.  

  ETSI  TR  103  411  (SAREF  Extension  Investigation)  mainly  describes  the  use  cases  on  which 
SAREF4ENER is based, rather than data elements. Therefore, it does not satisfy the criterion 
SL1  in  Section  3.2.  Note  that  although  TR  103  411  presents  a  useful  instantiation  of 
SAREF4ENER,  this  instantiation  does  not  add  information  in  terms  of  semantic  coverage 
compared to the SAREF4ENER specification that is already part of the short list. 
IEC TR 62746-2 and IEC TS 62913-2-3 are relevant for this study and the interfaces of interest, 
but they describe use cases and provide limited input to the identification of data elements 
for alignments. Therefore, they do not satisfy the criterion SL1 in Section 3.2. 

 

  oneM2M  TS  0001  describes  the  oneM2M  Functional  Architecture,  therefore  it  does  not 
contain data definitions that allow us to extract data elements, as required by criterion SL1 in 
Section 3.2. Note that, however, the oneM2M TS 0012 specification is included in the short 
list, as it specifies the oneM2M Base Ontology, which is suitable for data alignments.  

  The  OpenADR  specification  has  a  similar  semantic  coverage  to  the  IEC  CIM  standard.  A 
mapping effort is currently being performed between OpenADR and IEC CIM. As it is out of 
scope to duplicate efforts already being done elsewhere, openADR is not in the short list. 
  SPINE is an industry specification that has been used in CENELEC as a basis to the EN 50631-1 
standard,  and  by  ETSI  as  a  basis  to  create  SAREF4ENER.  Therefore,  the  relevant  data 
elements from SPINE are fully covered by EN 50631-1 and SAREF4ENER, which are part of the 
short list. 

3.4.3  Positioning of standards 
Figure 3-1 positions the short-list standards with respect to the corresponding interfaces in the scope 
of our study (i.e., S1, S2, G3, H2 and H1).  

Digital 
Single 
Market 

 
 
Figure 3-1: Short-list standards considered in the DSF study, positioned with respect to their corresponding interfaces in the 
DSF flow  

3.4.4  Mapping of use cases, interfaces and standards 
As shown in Table 3-3, it can be concluded that SAREF and SAREF4ENER classes sufficiently cover the 
identified use cases and the associated data elements from task 1 (see Section 2). This means that 
SAREF and SAREF4ENER provide a good basis as a “common mapping tool” to the other short-listed 
standards  selected  in  this  study  to  create  interoperability  within  Demand  Side  Flexibility.  The 
alignment  of  the  short-list  standards  via  SAREF  and  SAREF4ENER  as  a  common  mapping  tool  is 
elaborated in Section 4. 

This conclusion has been drawn from an assessment that compared 1) the data elements associated 
with the main use cases (see Section 2.3.3); and 2) the ‘Description of semantic coverage and main 
data elements’ of SAREF and SAREF4ENER (see Section 3.3.2). The result of the assessment is shown 
in  Table  3-3,  which  provides  an  initial  mapping  of  use  cases,  corresponding  data  elements  and 
interfaces onto SAREF and SAREF4ENER classes. This table is used as basis for further alignments to 
the other short-listed standards in Section 4. 

Table 3-3: Mapping of use cases, corresponding data elements and interfaces with SAREF and SAREF4ENER classes 

Involved 
interfaces  

S2 

Use cases 

Data elements 

SAREF and SAREF4ENER classes 

# 1: Device 
Registration & 
Configuration 

Device (ID and capabilities) 

saref:Device  
saref:hasManufacturer 
saref:hasModel 
saref:hasFunction 
saref:controlsProperty 
saref:measuresProperty 

saref:Actuator 
saref:Appliance saref:HVAC 
saref:LightingDevice  saref:Meter  
saref:Sensor  
etc. 

s4ener:Device 
s4ener:deviceName 
s4ener:deviceCode 

Digital 
Single 
Market 

 
 
 
 
 
 
 
 
s4ener:serialNumber 
s4ener:softwareRevision 
s4ener:hardwareRevision 
s4ener:vendorName 

# 2: Flexible start of 
Smart Device 

Control parameters, e.g. profile 
selection 

s4ener:AlternativesGroup 
s4ener:PowerSequence 

S1, S2, H2, 
G3 

Energy Profile 

s4ener:PowerProfile 

Preferred time slot of operation per 
device 

s4ener:Slot 

Energy consumption 

Flex start enabled 

Start time/ time slot of operation; 
Recalculated start time/ time slot 

New tariff info 

Operation commands 

Emergency signal 

Emergency load command 

s4ener:Energy 
s4ener:Power 

s4ener:StartTime 
s4ener:EndTime 
s4ener:EarliestStartTime 
s4ener:LatestEndTime, etc. 

saref:Price   

saref:Command 

s4ener:LoadControlEventAction 
s4ener:EventActionConsume 
s4ener:EventActionProduce 

s4ener:pause, resume, reduce, 
increase, emergency, normal 

S1, S2, H2 

# 3: Home 
response to 
Emergency 

S1, S2, G3 

# 4: Control of non-
smart Device by 
CEM (user settings) 

Tariff threshold 

Real Time Tariff 

Operation commands (increase or 
decrease power, turn off/on) 

ID of participating devices 

S1, S2, G3 

# 5: Direct Load 
Control of Smart 
Device via CEM 

saref:Price 
saref:Currency 
saref:Time 

saref:Command 

s4ener:Device 
s4ener:deviceName 
s4ener:deviceCode 

Power thresholds 

s4ener:Power 

Load management signal 

Load adjustment command 

Feedback about adjustment 

s4ener:LoadControlEventAction  
s4ener:EventActionConsume 
s4ener:EventActionProduce 
s4ener:pause, resume, reduce, 
increase, emergency, normal 

Expected change in consumption 

s4ener:PowerExpected 
s4ener:EnergyExpected 

S1, S2, G3 

# 6: Demand/ 
Supply adjustment 

Price information of electrical 
energy based on time of use 

saref:Price 
saref:Currency 

Planned load profile (expected 
consumption in time) 

s4ener:PowerExpected 
s4ener:EnergyExpected 

Digital 
Single 
Market 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
S1, S2, H1, 
H2, G3 

# 7: Exchange 
information on 
(partial) 
consumption 

saref:Measurement  
s4ener:Power   
saref:PowerUnit  
s4ener:Energy 
saref:EnergyUnit 

Consumption/Generation 
  Actual Individual 

Appliances (= partial) 
consumption/generation 
Forecasted partial 
consumption/generation 

 

  Actual total house 
consumption 
Forecasted total house 
consumption 

 

S1, S2, G3 

# 8: Smart device 
status retrieval 

Device Status 

saref:Device 
saref:State 

S1, H2 

S1, H2 

# 9: Time info CEM 
& Smart Meter 
Gateway 

Actual time 

saref:Meter 
saref:Time 
time:TemporalEntity 
time:DurationDescription 

# 10: Smart Meter 
Gateway notifies 
actual tariff to CEM 

Active tariff notification 

saref:Meter 
saref:EventFunction 
saref:NotifyCommand saref:Price  

Digital 
Single 
Market 

 
 
 
 
 
 
 
 
 
4. Alignments and Actions 
4.1  Objective  
This  study  enables  semantic  interoperability  between  DSF  standards  by  aligning  them  on  some  so-
called  core  data  elements  (or  core  concepts).  Core  data  elements  are  defined  here  as  recurring, 
common concepts in the DSF domain that define the meaning (or semantics) of the data exchanged 
between  standards.  For  instance,  a  core  data  element  is  Power  from  which  more  detailed  data 
elements  and  attributes  can  be  derived,  such  as  Cumulative  Power  or  Instantaneous  Power.  A  gap 
occurs when one or more core data elements in the DSF domain are missing in one of the standards 
under consideration or have a different meaning in different standards.  

The goal of task 3 (alignments) was to establish the level of alignment of the short-listed standards, 
identify gaps among them and define actions to reach alignment. 

4.2  Approach  
Starting point 
The SAREF and SAREF4ENER ontologies have been used in this study as a “common mapping tool” to 
align short-listed standards to create semantic interoperability, or, in other words, as the overarching 
ontologies  to  enable  semantic  interoperability  between  DSF  standards.  SAREF  was  created  in  a 
previous  study  for  the  European  Commission  [4]  with  a  bottom-up  approach  using  23  so-called 
“semantic  assets”  (i.e.,  standards,  data  models,  protocols,  ontologies,  specifications)  relevant  for 
smart  appliances,  which  provided  the  core  concepts  to  make  SAREF  interoperable  by  design.  The 
underlying  assumption  in  this  study  was  that  if  the  standards  in  our  short-list  are  aligned  with  the 
core concepts in SAREF/SAREF4ENER, then these standards are also aligned with each other on the 
same core concepts. 

Comparing standards 
In  order  to  facilitate  the  task  of  the  alignment  of  standards,  there  are  various  ontology  matching 
algorithms22  can  support  the  comparison  automatically  [8].  These  algorithms  take  as  input  files 
expressed in the OWL format23, which is typically used to represent ontologies. However, the short-
listed standards selected in this study not always provide OWL files nor suitable files (such as XSD and 
UML)  that  can  be  translated  to  OWL,  meaning  that  for  these  standards  a  manual  comparison  was 
required. 

-  Automatic  approach:  For  the  automatic  comparison,  TNO  has  created  an  alignment-
application  that  creates  an  alignment  based  on  the  similarity  between  class  names  in 
SAREF/SAREF4ENER and data element names in the short-listed standards. The class-name-
similarity  is  calculated  by  the Python-module  FuzzyWuzzy24  that comes  with  out-of-the-box 
string-comparison algorithms that are based on the Levenshtein-distance25. The Levenshtein-
distance is defined as the number of single-character edits to convert one input in the other 
[9].  We  used  the  algorithms  fuzz.ratio,  which  takes  a  full  class  name  and  uses  the 
Levenshtein-distance  in  order  to  calculate  a  similarity  score),  and  fuzz.partial_ratio,  which 
performs  the  same  similarity  function  also  on  substrings.  In  order  for  two  classes  to  be 

22 http://www.mkbergman.com/1769/50-ontology-mapping-and-alignment-tools/ 
23 http://www.w3.org/TR/owl-features/ 
24 https://github.com/seatgeek/fuzzywuzzy 
25 https://xlinux.nist.gov/dads/HTML/Levenshtein.html 

Digital 
Single 
Market 

 
 
                                                            
matched, one of these two algorithms has to return a similarity score greater than 70. Note 
that  this  approach  is  only  used  to  find  similar  classes  in  both  standards.  However,  this 
approach does not consider properties, class relationships or similar (i.e., we compared only 
data elements to each other, but NOT attributes of these data elements). The results of the 
alignment-application  were  manually  filtered  by  the  study  team  (i.e.,  domain  experts  with 
specific  knowledge  about  the  standards)  and  clustered  into  high-level  concepts.  Clustering 
was based on similar terms like “Device”, “Energy”, “Power” and “Time”, which we refer to 
as core concepts. 

-  Manual approach: When the automatic approach was not possible, we inspected manually 
the  PDF  specifications  of  the  short-listed  standards,  extracted  the  DSF  core  data  elements 
and compared them to SAREF/SAREF4ENER using a table format. 

Alignment 
This  study  considered  that  the  alignment  on  a  certain  data  element  was  reached  when  a)  the  two 
standards  under  comparison  both  covered  that  data  element;  and  b)  the  meaning  of  that  data 
element was the same in both standards. In some cases the alignment was not straightforward (i.e., 
it  was  not  a  one  to  one  mapping  from  one  standard  to  the  other),  but  it  could  still  be  reached  by 
extending an existing class in SAREF. For instance, the concept of “Volume” does not exist explicitly in 
SAREF,  but  the  class  “Property”  does  exist,  which  is  the  upper  class  for  concepts  like  “Power”, 
“Energy”  and  “Temperature”.  One  can  therefore  create  a  new  class  “Volume”  as  subclass  of  the 
existing “Property” class.  

A  gap  occurred  when  the  mapping  was  not  possible  at  all,  because  the  data  element  under 
consideration  did  not  exist  in  SAREF  or  in  one  of  the  considered  standards,  or  the  meaning  was 
different. For instance, SAREF does not define the “Status” of the meter reading, therefore, it could 
be considered to extend SAREF with a new property to express this additional information. 

Maturity level of alignments 
The  standards  considered  in  this  study  are  heterogeneous  in  the  way  they  express  semantics  and 
only some of these standards provide a suitable format that can be used straightforward as input for 
an automated alignment. A suitable format for automated alignment, and used in this study, is the 
OWL format, which enables to formally capture the semantics of a specification.  

- 

- 

- 

Four standards explicitly provide executable semantics by means of an ontology expressed in 
the OWL format, these are: SAREF and SAREF4ENER ontologies, the KNX ontology (EN 50090) 
and the oneM2M ontology.  
Three standards provide a format that can be automatically translated to OWL, such as XML 
schema  (XSD)  or  UML,  these  are:  EN  50631-1  (SPINE),  whose  data  model  is  expressed  as 
XSDs,  and  IEC  61970  CIM  and  61968-9  CIM  for  Metering,  whose  semantics  is  expressed  in 
UML.  
The remaining three standards, i.e., CEN 16836 (ZigBee SEP2), CENELEC EN 50491-11 Smart 
Metering and IEC/CENELEC 62056 COSEM, currently do not explicitly capture the semantics 
of their data elements, which remains hidden in the data model and needed to be manually 
extracted from the PDF specifications.  

Digital 
Single 
Market 

 
 
 
This heterogeneity has led to a different maturity level of the alignments proposed in this study, and 
as  a  result,  a  different  way  of  presenting  and  visualizing  the  alignments.  For  some  alignments,  an 
automated tool could be used for ontology alignment and generating a complete visualization of the 
results accordingly, while other alignments needed to be performed manually and are visualised by 
means of a (less sophisticated) mapping table. 

4.3  Technical analysis  
4.3.1  Alignment and Actions for CEN EN 16836 (ZigBee SEP2) 

Input for Alignment 

The  EN  16836  series  of  standards  is  specified  by  CEN  TC  294  (Communication  systems  for  meters) 
that  not  only  has  a  technical  liaison  agreement  with  The  ZigBee  Alliance  in  order  to  exchange 
documents,  share  knowledge  and  report  on  meetings,  but  is  also  allowed  to  reference  published 
ZigBee  documents  due  to  a  Memorandum  of  Understanding  (MOU)  in  place  between  the 
organisations  under  the Consortium  Bridge procedure  within CEN/CENELEC.  One of  the referenced 
documents by EN 16836 is the “ZigBee Smart Energy Profile Specification Standard – 07-5356 Rev 19, 
December  3,  2014”,  which  is  also  the  document  used  in  this  study  as  input  for  the  alignment 
(available in PDF format at http://www.zigbee.org/about/centc294). 

Earlier alignments 

The earlier “Smart Energy Profile 2 (SEP2) Application Protocol Standard, ZigBee Public Document 13-
0200-00, April 2013”26 document has been used as basis to create SAREF in the previous study for the 
European Commission on “Semantic Assets for Smart Appliances Interoperability” [4]. Therefore, an 
alignment  of  the  CEN  EN  16836  series  with  SAREF  already  exists  via  the  mapping  of  the  “SEP2 
Application  Protocol  Standard  (2013)”  onto  SAREF  performed  in  [4],  which  was  based  on  the 
following SEP2 data elements: 

-  Commodity Type (e.g., Electricity, Air, Natural Gas, Potable Water, Waste Water, Heating Fluid) 
-  Device  Category  (e.g.,  Thermostat,  Water  Heater,  Pool  Pump,  Smart  Appliance,  Irrigation 

Pump, Exterior Lighting, Interior Lighting, Electric Vehicle) 
Service Kind (e.g., Electricity, Gas, Heat) 

- 
-  Device Status (e.g., Operating, Starting up, Shutting down) 
-  Device Information (e.g., Manufacturer, Model Number, Serial Number, Software Version) 
-  Unit of Measure Type (e.g., kWh, kW, Watts, Cubic Meters, Kelvin, Celsius) 

Analysis 

A further alignment is performed in this study to determine correspondences and/or gaps between 
the CEN EN 16836 (ZigBee SEP2) and SAREF/ SAREF4ENER27 data elements described in Section 3.3.2. 
We performed this mapping manually  (see approach in Section 4.2) using as basis the ZigBee SEP2 
specification  available  in  PDF  format  at  http://www.zigbee.org/about/centc294.  We  have  manually 
extracted  the  semantic  coverage  and  main  data  elements  from  the  ZigBee  SEP2  specification  (see 

26 Note that the “Smart Energy Profile 2 Application Protocol Standard, ZigBee Public Document 13-0200-00, April 2013” is an 
earlier version than the “ZigBee Smart Energy Profile Specification Standard – 07-5356 Rev 19, December 3, 2014” used for 
alignment in this study 
27 Note that the alignment performed in [4] was between ZigBee SEP2 and SAREF, while the current alignment considers a 
new version of ZigBee SEP2 specification and also SAREF4ENER (which did not exist yet at the time of the first study in [4]).  

Digital 
Single 
Market 

 
 
                                                            
Section  3.3.2  for  details  on  these  data  elements)  and  compared  it  to  the  core  concepts  for  DSF  in 
SAREF/  SAREF4ENER,  using  Table  3-3  as  a  mapping  tool.  The  resulting  alignment  is  shown  in  Table 
4-1. 

Table 4-1: Alignment of CEN EN 16836 (ZigBee SEP2) with SAREF/SAREF4ENER  

SAREF/SAREF4ENER  

Common data elements 

EN 16836 (ZigBee SEP2)  

Device (ID and 
capabilities) 

Device types: 
Load Control Device, 
Smart Appliance Device,  
Programmable Communicating 
Thermostat (PCT) Device,  
Metering Device 

saref:Device  
saref:hasManufacturer 
saref:hasModel 
saref:hasFunction 
saref:controlsProperty 
saref:measuresProperty 

saref:Actuator 
saref:Appliance saref:HVAC 
saref:LightingDevice  saref:Meter  
saref:Sensor  
etc. 

s4ener:Device 
s4ener:deviceName 
s4ener:deviceCode 
s4ener:serialNumber 
s4ener:softwareRevision 
s4ener:hardwareRevision 
s4ener:vendorName 

! 

! 

! 

s4ener:AlternativesGroup 
s4ener:PowerSequence 

Control parameters, e.g. 
profile selection 

s4ener:PowerProfile 

Energy Profile 

s4ener:Slot 

s4ener:Energy 
s4ener:Power 

s4ener:StartTime 
s4ener:EndTime 
s4ener:EarliestStartTime 
s4ener:LatestEndTime 
etc. 

saref:Price   

saref:Command 

Preferred time slot of 
operation per device 

Energy consumption 

Consumption  

Start and end times to avoid spikes 

Flex start enabled 
Start time/ time slot of 
operation 
Recalculated start time/ 
time slot 

New tariff info 

Generated (delivered) prices 

Operation commands 

Control methods  for Demand 
Response/Load Control 

s4ener:LoadControlEventAction 
s4ener:EventActionConsume 
s4ener:EventActionProduce 

Emergency signal 

Events for Demand Response/Load 
Control  

Criticality levels: Green, Emergency, 
Planned Outage, Service Disconnect, 
Utility Defined 

Emergency load 

Digital 
Single 
Market 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
s4ener:pause, resume, reduce, 
increase, emergency, normal 

command 

Control methods  for Demand 
Response/Load Control  

saref:Price 
saref:Currency 
saref:Time 

Tariff threshold 

Real Time Tariff 

Price, Multiple currencies for 
international support (using ISO 4217), 
Time  

Demand response or pricing events for 
Smart Appliance device informing 
customers via in-home displays 

Generation (delivered) and 
consumption (received), Units of 
measure 

Events for Demand Response/Load 
Control 

Control methods for Demand 
Response/Load Control 

Generated (delivered) and consumed 
(received) prices 
Multiple currencies for international 
support (using ISO 4217) 

Time; 
Generation (delivered) and 
consumption (received); 
Measurement types (such as load 
profile), Units of measure 

Measurement types for Load Control 
Device, Smart Appliance Device and 
Metering Device; 
Units of measure; 
Generation (delivered) and 
consumption (received); 
Real-time information 

saref:Command 

s4ener:Device 
s4ener:deviceName 
s4ener:deviceCode 

Operation commands 
(increase or decrease 
power, turn off/on) 

ID of participating 
devices 

s4ener:Power 

Power thresholds 

s4ener:LoadControlEventAction  
s4ener:EventActionConsume 
s4ener:EventActionProduce 

s4ener:pause, resume, reduce, 
increase, emergency, normal 

s4ener:PowerExpected 
s4ener:EnergyExpected 

saref:Price 
saref:Currency 

s4ener:PowerExpected 
s4ener:EnergyExpected 

saref:Measurement  
s4ener:Power   
saref:PowerUnit  
s4ener:Energy 
saref:EnergyUnit 

Load management signal 

Load adjustment 
command 

Feedback about 
adjustment 

Expected change in 
consumption 

Price information of 
electrical energy based 
on time of use 

Planned load profile 
(expected consumption 
in time) 

Consumption/Generatio
n 

  Actual Individual 
Appliances (= 
partial) 
consumption/gener
ation 
Forecasted partial 
consumption/gener
ation 

 

  Actual total house 
consumption 
Forecasted total 

 

Digital 
Single 
Market 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
saref:Device 
saref:State 

saref:Meter 
saref:Time 
time:TemporalEntity 
time:DurationDescription 

house consumption 

Device Status 

Actual time 

Status indicators (e.g. battery low, 
tamper detected) 

Metering Device; 
Time; 
Real-time information 

saref:Meter 
saref:EventFunction 
saref:NotifyCommand saref:Price  

Active tariff notification  Metering Device; 

Price, Multiple currencies for 
international support (using ISO 4217); 
Real-time information 

As  is  shown  in  Table  4-1,  the  main  data  elements  from  the  CEN  EN  16836  standard  (ZigBee  SEP2) 
provide an exhaustive coverage to the SAREF/ SAREF4ENER classes that are relevant for the DSF use 
cases (data elements in green in the table). The type of devices of interest for the DSF study are well 
covered  by  CEN  EN  16836  (ZigBee  SEP2),  such  as  Metering  Device,  Programmable  Communicating 
Thermostat (PCT) Device, which can control the premises heating and cooling systems, Load Control 
Device, which can receive Demand Response and Load Control events to manage consumption on a 
range  of  devices,  and  Smart  Appliance  Device,  which  can  participate  in  energy  management 
activities. Measurements, consumption and generation of e.g., energy and power are also covered in 
CEN  EN  16836  (ZigBee  SEP2),  together  with  the  possibility  to  express  price  and  time  information 
when, for example, Utilities initiate a demand response or pricing event. 

Gaps 
The  data  elements  highlighted  in  red  in  Table  4-1  show  that  a  gap  exist  in  CEN  EN  16836  (ZigBee 
SEP2)  concerning  the  possibility  for  Smart  Appliance  Devices  participating  in  energy  management 
activities to express complex power profiles and optimal time slots for operation, also based on user 
preferences.  As  it  is  shown  in  Table  4-1,  concepts  related  to  Energy/Power  Profile,  such  as 
“s4ener:AlternativesGroup”,  “s4ener:PowerProfile”,  “s4ener:PowerSequence”  and  “s4ener:Slot”, 
which are essential for the Use case# 2: Flexible start of Smart Device considered in this study, do not 
find corresponding data elements in the CEN EN 16836 (ZigBee SEP2) standard.  

Actions 

Action owners 

Action 

A-1 

CLC/TC 294 

Include  Power  Profile  and  associated  concepts  (i.e.,  Power  Profile 
Alternatives  Group,  Power  Sequence,  Slot  and  corresponding 
attributes) 
in  CEN  EN  16836  (ZigBee  SEP2).  Or,  explicitly 
acknowledge if these concepts are out of scope of  CEN EN 16836 
(ZigBee  SEP2)  and  provide  explicit  indication  of  which  other 
international  standard  should  be  used  to  cover  these  missing 
concepts. 

Digital 
Single 
Market 

 
 
 
 
 
 
 
 
 
An  additional  observation  is  that  the  EN  16836  (ZigBee  SEP2)  standard  defines  detailed  data 
elements  also  for  other  type  of  meters  other  than  electricity  meters  (e.g.,  gas,  water  and  heat 
meters).  In  contrast,  SAREF  explicitly  defines  only  electricity  meters,  but  provides  the  capability  to 
derive  other  type  of  meters  from  existing  classes.  For  example,  the  two  new  subclasses 
“saref:GasMeter” and “saref:WaterMeter” can be created from the existing “saref:Meter” class, and 
associated with the already existing commodity types “saref:Gas” and “saref:Water”. 

Action owner 

Action 

A-2 

ETSI SmartM2M TC 

Consider  the  possibility  to  explicitly  extend  SAREF  to  cover 
additional  type  of  meters  and  related  measurements  (e.g.,  gas, 
water, heat, etc.) other than electricity meters, if relevant. 

The CEN EN 16836 (ZigBee SEP2) standard defines various types of metering, measurements types, 
real-time readings, historical information, status indicators, etc.,  analogously to other standards  on 
the same interface (H1 and H2), such a IEC 62056 COSEM and CENELEC EN 50491-11 Smart Metering. 
is  unclear  to  which  extent  these  standards  express  overlapping  and/or  complementary 
It 
information.  Therefore,  an  action  is  necessary  to  clarify  this,  provide  mappings  where  needed  and 
reduce duplication of work and efforts in different Technical Committees that specify standards with 
similar scope on the same interface.  

Action owners 

Action 

A-3 

CLC/TC  294,  CLC/TC 
205  and  IEC/CLC/TC 
13 WG 14 

There  are  various  smart  meter  standards  used  for  the  same 
interface  (H1/H2),  i.e.,  CEN  EN  16836  (ZigBee  SEP2),  CENELEC  EN 
50491-11  Smart  Metering,  and  IEC  62056  COSEM.  Investigate 
overlapping  between  these  standards,  provide  mappings  and 
reduce  duplication  of  work  and  efforts  in  different  Technical 
Committees. 

4.3.2  Alignment and Actions for IEC 62056 COSEM 

Input for Alignment 

Companion  Specification  for  Energy  Metering  to  IEC  62056-6-2  from  DLMS  User  Association,  Blue 
Book,  12th  edition  “COSEM  Identification  System  and  Interface  Classes”  (free  excerpt  available  at 
http://dlms.com/documentation/index.html). 

Earlier alignments 

The companion specification to IEC 62056-6-2 from DLMS titled “Companion Specification for Energy 
Metering: COSEM interface classes and OBIS identification system”, 11th edition (also called the “Blue 
Book” specification), has been analysed as part of the long list of standards relevant to create SAREF 
in  the  earlier  study  for  the  European  Commission  on  “Semantic  Assets  for  Smart  Appliances 
Interoperability”  [4].  However,  it  was  not  included  in  the  short-list  that  was  directly  mapped  onto 
SAREF. 

Digital 
Single 
Market 

 
 
 
 
 
 
Analysis 

An alignment was performed in this study to determine precise correspondences and eventual gaps 
between IEC 62056 COSEM and SAREF/ SAREF4ENER28. Unfortunately, it was not possible to exploit 
the ontology alignment algorithm described in Section 4.2 to make this alignment in an automated 
way29. Therefore, we performed the alignment manually. Given the extension and complexity of the 
COSEM data model and OBIS identification system, we compared with corresponding concepts from 
SAREF/  SAREF4ENER  only  the  OBIS  codes  relevant  to  this  study,  i.e.,  those  that  define  the  media 
(energy  type)  to  which  the  metering  is  related  (OBIS  codes  from  group  A  in  the  Blue  Book).  The 
resulting alignment is shown in Table 4-2. 

Table 4-2: Alignment of IEC 62056 COSEM with SAREF/SAREF4ENER  

Common data 
elements 

Power 

Energy 

Value type (for 
Electricity) 

Time 

SAREF/SAREF4ENER  

saref:Power, 
s4ener:PowerExpected, 
s4ener:PowerMax, 
s4ener:PowerMin, 
s4ener:PowerSkewness, 
s4ener:PowerStandardDeviation 

saref:Energy, 
s4ener: Energy Expected,  
s4ener: Energy Max,  
s4ener: Energy Min,  
s4ener: Energy Skewness,  
s4ener: EnergyStandardDeviation, 
s4ener: ResumeEnergyEstimated 

saref:Electricity, 

saref:Power, 
s4ener:PowerMax, 
s4ener:PowerMin, 
saref:Energy, 
s4ener: Energy Max,  
s4ener: Energy Min 
saref:Time, 
time:DurationDescription, 
time:TemporalEntity (Instant or 
Interval), 
saref:Measurement hasTimestamp 

OBIS codes/COSEM object 

Electrical Related 
Objects (A= 1)30 

Value group C codes A=1: 
Active power,  
Reactive power,  
Apparent power,  
etc. 

General purpose codes A=1: 
Active energy, 
Reactive energy, 
Apparent energy, 
etc. 

Value group D codes A=1: 
Minimum, 
Maximum, 
Cumulative, 
Average,  
Instantaneous, 
Threshold, etc. 

General purpose codes A=1: 
Timestamp billing period, 
Measurement period, 
Recording interval,  
etc. 

28 Note that this alignment also considers SAREF4ENER, which did not exist yet at the time of the first study on SAREF in [4] 
was performed. 
29 The reason is that COSEM has an extensive and complex data model based on the Object Identification System (OBIS). The 
semantics of the COSEM data elements and OBIS codes is not explicitly formalized in a machine readable format (such as 
OWL). Therefore, we had to extract the semantics manually from the corresponding PDF document (making it impossible to use 
the ontology alignment tool, which is not able to analyse an input in PDF format).   
30 For the complete list of data elements in COSEM related to Electricity, see section 5.5 of the Blue Book (Table 20 to Table 
27). 

Digital 
Single 
Market 

 
 
 
                                                            
xsd:dateTime 
! No Status (as quality of the 
measurement), but only State (of 
the device) in SAREF.  

Action: create a new property 
“Status” to be added to the 
saref:Measurement class in SAREF 

saref:State 

saref:Temperature 

Status (quality 
of the 
measurement) 

General purpose codes A=1: 
Status info missing voltage,  
Status info missing current, 
Status info current without 
voltage, 
Status info auxiliary power 
supply 

State (of the 
device) 

Abstract Object 
(A=0) 

Internal Operation Status  

Heat 
(Temperature) 

Heat Cost Allocator 
Related Object 
(A=4)31 

! there is no saref:Volume,  
(but it can be created as subclass of 
saref:Property) 

Heat/Cooling 
(Volume) 

Heat/Cooling 
Related Object (A=5 
or A=6)32 

saref:Gas,  
saref:Temperature,  
saref:Pressure 

Gas (Volume, 
Temperature, 
Pressure) 

Gas Related Objects 
(A= 7)33 

! there is no saref:Volume  
(but it can be created as subclass of 
saref:Property) 

Value group C codes A=4: 
Radiator surface 
temperature, Heating 
medium temperature, Flow 
(forward) temperature, 
Return temperature,  
Room temperature, etc. 

Value group C codes A=5 or 
A=6:  
Accounted volume,  
Flow volume,  
Return volume, etc. 
Value group C codes A=7: 
Forward undisturbed meter 
volume, Forward disturbed 
meter volume, Forward 
absolute meter volume, 
Reverse undisturbed meter 
volume, Reverse disturbed 
meter volume, Reverse 
absolute meter volume, 
Forward undisturbed 
converter volume, Forward 
undisturbed logger volume, 
Forward undisturbed 
Energy, Absolute 
temperature, Absolute 
pressure, etc.  

saref:Water,  
saref:Temperature 

Water 

Cold Water Related 
Object (A=8) and 

Value group C codes A=8 
and A=9: 

31 For the complete list of data elements in COSEM related to Heat Cost Allocator (HCA), see section 5.6 (Table 32) of the Blue 
Book.  
32 For the complete list of data elements in COSEM related to Heat/Cooling, see section 5.7 (Table 38 to Table 40) of the Blue 
Book.  
33 For the complete list of data elements in COSEM related to Gas, see section 5.8 (Table 44 to Table 46) of the Blue Book.  

Digital 
Single 
Market 

 
 
 
 
 
                                                            
! there is no saref:Volume 

Hot Water Related 
Object (A=9)34 

Accumulated volume,  
Flow rate,  
Forward temperature, etc. 

As it is shown in Table 4-2, there is a fair level of alignment (see common data elements coloured in 
green in the table, such as Power, Energy, Value Types, Time, State and Temperature) between IEC 
62056  COSEM  and  SAREF/  SAREF4ENER.  Green  alignment  should  be  intended  as  interoperability  is 
currently possible, since SAREF/ SAREF4ENER provides the facility (i.e., an upper class and a text field) 
to express that concept. However, some ad-hoc adjustments may still need to be done. For example, 
consider the core concepts “Power” and “Value type (for Electricity)” in Table 4-2. On the one hand 
(see left side in the table), SAREF defines “saref:Power” and SAREF4ENER specific power value types, 
such as “s4ener:PowerMax” and “s4ener:PowerMin”. On the other hand (see right side in the table), 
COSEM  needs  additional  value  types  for  power,  such  as  “Cumulative  Power”  and  “Instantaneous 
Power”,  for  which  there  is  not  an  explicit  class  in  SAREF/  SAREF4ENER.  The  ad-hoc  adjustment 
consists,  in  this  case,  of  creating  an  instance  of  “saref:Power”  called  “saref:CumulativePower”  and 
indicate in the corresponding text field description that this is cumulative power.  

Note that the alignment between SAREF/SAREF4ENER and COSEM using this type of adjustments has 
been  successfully  implemented  in  the  demonstrator  of  interoperability  for  DSF  resulting  from  this 
study  (see  “Appendix  C  -  Detailed  description  of  the  demonstrations”).  In  this  demonstrator,  an 
Energy  Gateway  uses  SAREF/  SAREF4ENER  as  overarching  ontology  to  combine  data  metering 
readings represented by COSEM objects and OBIS addresses (on interface H2), with data represented 
by oneM2M resources (on interface G3). 

Gaps 

The  alignment  in  Table  4-2  further  shows  that  there  are  some  gaps  in  SAREF/SAREF4ENER  (see 
common data elements coloured in red in the table) when it comes to the following data elements: 

  Status of the meter reading (intended not as device status, but as the  status/quality of the 
measurement provided by the device, i.e., “Status info missing voltage”, “Status info missing 
current”, “Status info current without voltage”, “Status info auxiliary power supply”, etc.). As 
this  concept  does  not  currently  exist  in  SAREF  (therefore  the  gap),  it  can  be  considered  to 
create it by extending SAREF with e.g. a new property called “saref:hasMeterReadingStatus” 
to be added to the existing saref:Measurement class.  

  Specific parameters related to Gas, Water and Heat meters, such as Volume. As the concept 
of  “Volume”  does  not  explicitly  exist  in  SAREF  (therefore  the  gap),  it  can  be  considered  to 
create  it.  This  can  be  done  using  the  class  “saref:Property”,  which  is  the  upper  class  for 
already  existing  concepts  like  “saref:Power”,  “saref:Energy”  and  “saref:Temperature”.  Next 
to  the  classes,  a  new  class  “saref:Volume”  could  be  created  as  subclass  of  the  existing 
“saref:Property” class. 

Actions 

Action owner 

Action 

34 For the complete list of data elements in COSEM related to Water, see section 5.9 (Table 50 to Table 52) of the Blue Book  

Digital 
Single 
Market 

 
 
 
 
                                                            
A-4 

ETSI SmartM2M TC 

Consider to extend SAREF to fill the identified gaps with IEC 62056 
COSEM (see red elements in Table 4-2), if relevant. These gaps 
concern the status of the meter reading (intended as quality of the 
reading), and specific parameters related to Gas, Water and Heat 
meters, such as Volume. 

As already observed for EN 16836 (ZigBee SEP2), also IEC 62056 COSEM defines detailed data 
elements for other type of meters other than electricity meters (e.g., gas, water and heat meters), 
while SAREF explicitly defines only electricity meters.  

Action owner 

Action 

A-535  ETSI SmartM2M TC 

Consider to explicitly extend SAREF to cover additional type of 
meters and related measurements (e.g., gas, water, heat, etc.) 
other than electricity meters. SAREF already provides the capability 
to derive other type of meters from existing classes. For example, 
new subclasses such as “Gas Meter” and “Water Meter” can be 
created from the existing “saref:Meter” class and associated with 
the already existing commodity types “saref:Gas” and 
“saref:Water”. The suggested classes could be created either as 
part of the SAREF core ontology or the already existing 
SAREF4ENER. Another option could be to start a new extension of 
SAREF explicitly dedicated to the Smart Metering domain, if 
relevant.  

An additional action concerns the green alignments in Table 4-2. It was mentioned for these 
alignments that interoperability is currently possible, since SAREF/ SAREF4ENER provides the facility 
(i.e., an upper class and a text field) to express that concept. However, some ad-hoc adjustments 
may still need to be done, such as create an instance of “saref:Power” called “Cumulative Power” or 
“Reactive Power” and indicate in the corresponding text field description that this is cumulative 
power or reactive power.  

Action owner 

Action 

A-6 

IEC/ CENELEC TC 13 
WG 14, but also 
SAREF users in 
general 

When ad-hoc adjustments on SAREF/SAREF4ENER need to be done 
on a regular basis in different projects (recurrent adjustments), 
consider to submit a request to ETSI SmartM2M TC, so that an 
updated version of SAREF that incorporates these adjustments 
could possibly be released. For example, if one has to define 
recurrently in their own projects a “myproject:ReactivePower” 

35 Note that A-5 is an extension of the action A-2 already defined in Section 4.3.1 

Digital 
Single 
Market 

 
 
 
 
 
 
                                                            
instance from the existing “saref:Power” class, it would be 
beneficial to provide feedback to ETSI SmartM2M TC36, requesting 
to create a class “saref:ReactivePower” (instead of having to define 
a “myproject:ReactivePower” instance over and over in different 
projects). 

4.3.3  Alignment and Actions for IEC 61968-9 CIM for metering 

Input for Alignment 

IEC  TS  62056-6-9:2016   -  The  DLMS/COSEM  suite  -  Part  6-9:  Mapping  between  the  Common 
Information  Model  message profiles  (IEC  61968-9)  and  DLMS/COSEM  (IEC  62056)  data  models  and 
protocols, available at https://webstore.iec.ch/publication/24736 to be purchased from IEC.    

Earlier alignments 

The  “DLSM/COSEM/CIM  Study  Report”  of  June  2010  and  the  subsequent  IEC  62056-6-9:2016 
Technical  Specification  from  the  joint  effort  of  IEC  TC  13  and  IEC  TC  57  address  the  alignment  of 
DLSM/COSEM  (IEC  62056)  to  CIM  for  metering  (IEC  61968-9).  In  particular,  the  IEC  62056-6-9 
Technical  Specification  covers  the  mapping  between  information  interchange  messages  of  a  CIM-
based ERP or third party system and a DLMS/COSEM-based metering system. 

Analysis 

Figure  4-1  shows  the  application  domain  and  the  need  for  integration  motivating  the  mapping 
between DSLM/COSEM and CIM for metering resulting by the joint effort of IEC TC 13 and IEC TC 57.  

Figure 4-1:  Integration of DLSM/COSEM with CIM (D.Taylor and M.Kozole, TC13/57 JWG16) 

In  the  “DLSM/COSEM/CIM  Study  Report”  of  June  2010,  message  profiles  are  provided  as  XSD 
schemas to be exchanged between the ERP system, metering system head-end and the end device, 
where the integration is realized at the metering system head-end. The advantage of these message 
profiles is that they are based on the CIM for metering, but also maintain the contextual relationship 
between  physical  device,  logical  device,  object,  attribute  and  method  exactly  as  is  defined  in  the 

36 All ETSI members can participate to SmartM2M TC meetings (usually held four times per year) and ad-hoc 
calls on SAREF related topics, to provide feedback on the use and evolution of SAREF. Contacts of the 
SmartM2M TC Officials and the schedule of the meetings can be found at https://portal.etsi.org/home.aspx  

Digital 
Single 
Market 

 
 
 
 
                                                            
DLMS/COSEM standards. Figure 4-2 shows the mapping approach of the CIM messages in the CIM for 
metering (IEC 61968-9) into DLMS services, OBIS codes and COSEM objects.  

Figure 4-2:  Mapping of CIM for metering message elements into DLSM/COSEM (D.Taylor and M.Kozole, TC13/57 JWG16)  

To enable the mapping, the “DLSM/COSEM/CIM Study Report” of June 2010 extends the CIM UML 
model  to  accommodate  the  COSEM  concepts  of  physical  device,  logical  device  and  associated 
objects. To that end, new classes in the CIM metering are created, such as the  PhysicalDevice class 
that  is  an  aggregation  of  one  or  more  logical  devices  (LogicalDevice  class),  which  in  turn  are 
aggregations  of  COSEM  objecs  (CosemObject  class).  Other  classes  such  as  CosemAttribute, 
CosemMethod, CosemData, and CosemResult are also part of this extension. In particular, a COSEM 
physical  device  is  created  as  subclass  of  the  EndDeviceAsset  class  of  the  CIM.  EndDeviceAsset  is  a 
child  class  in  the  inheritance  hierarchy  of  asset  classes  modelled  in  the  CIM.  End  devices  are 
(but  associated  with)  the 
conceptually  those  devices  physically 
ServiceDeliveryPoint  at  the  end  of  the  distribution  network.  In  this  context,  a  billing  meter  is  an 
EndDeviceAsset typically connected to the ServiceDelivery point. Thus, MeterAsset is a child class of 
EndDeviceAsset.  Note  that  the  COSEM  physical  device  is  modelled  as  a  subclass  of  EndDeviceAsset 
(rather than a MeterAsset) because COSEM objects may locate in devices other than meters. 

located  at  or  near  to 

Gaps 

The mapping between information interchange messages of a CIM-based ERP and a DLMS/COSEM-
based metering system is already taken care of by the joint initiative of IEC TC13 and IEC TC 57, which 
resulted in the IEC TS 62056-6-9:2016. As it is out of scope to duplicate efforts already being done 
elsewhere, we did not identify the immediate need of an additional mapping of CIM for metering to 
SAREF/ SAREF4ENER (the mapping can be realized at the moment via DLMS/COSEM, which is aligned 
to both CIM for metering and SAREF/SAREF4ENER).  

Actions 

CIM for metering is already aligned to DLSM/COSEM via ongoing initiatives. This is sufficient for the 
scope  of  this  study.  However,  it  may  be  worthwhile  in  the  future  to  further  look  at  the  direct 
mapping of CIM for metering and SAREF/SAREF4ENER. 

Action owner 

Action 

A-7 

IEC TC 13 and IEC TC  CIM  for  metering  is  aligned  with  SAREF/SAREF4ENER  through 
COSEM, meaning that interoperability is possible. IEC TC 13 and IEC 

Digital 
Single 
Market 

 
 
 
 
57 

TC  57  should  consider  if  interoperability  through  COSEM  is 
sufficiently  practicable.  Otherwise,  direct  alignment  with 
SAREF/SAREF4ENER could be explored. 

4.3.4  Alignment and Actions for IEC 61970 CIM 

Input for Alignment 

The IEC CIM is specified as UML class diagram and an official version of the entire CIM in the OWL 
format  published  by  IEC  TC  57  does  not  exist.  Therefore,  we  have  performed  our  own,  ad-hoc 
transformation of the CIM from UML to OWL37. The generated OWL version of the CIM for this study 
is available at http://ontology.tno.nl/DSFstudy/cim4alignment.ttl. 

Earlier alignments 

No earlier alignments have been explored. 

Analysis 

The  alignment  with  SAREF/SAREF4ENER  is  a  cumbersome  task  due  to  the  complexity  of  the  CIM, 
which  defines  about  1500  different  concepts  (classes)  and  a  multitude  of  properties  divided  over 
some 100 packages. To that end, we performed a transformation of the CIM from UML to OWL (see 
above), so that we could then perform the alignment automatically with our algorithm for ontology 
matching  (see approach in Section  4.2) using  as  input  the OWL  version  of  the CIM and  the SAREF/ 
SAREF4ENER  ontologies  (available  at  http://ontology.tno.nl).  The  resulting  alignment  is  shown  in 
Figure  4-3,  where  the  core  data  elements  in  the  middle  are  coloured  in  green  to  show  sufficient 
overlapping or in red when there is a possible gap and a consequent need for further action. 

37  We  have  applied  several  methods  for  this  transformation,  including  1)  the  UML  to  OWL 
transformation that comes prepackaged with TopBraid Composer,  2) the Sparkx Enterprise Architect 
schema composer export to RDFS, as well as 3) the same export function to XSD in combination with 
the  import  functionality  for  XSD  in  TopBraid  Composer.  The  XSD    (option  3)  was  the  most  fruitful. 
Using 
to  OWL  classes  and  associations, 
specialization/generalization, attributes and cardinality were transformed as expected. 

this  method,  UML  classes  were 

transformed 

Digital 
Single 
Market 

 
 
 
                                                            
Figure 4-3:  Alignment of IEC 61970 CIM with SAREF/ SAREF4ENER using the algorithm for ontology matching 

The  initial  results  obtained  with  the  ontology  matching  tool  show  that  there  is  a  certain  degree  of 
overlapping  with SAREF/  SAREF4ENER (see core  concepts in green in  Figure  4-3), although the CIM 
covers a much broader scope than DSF. This suggests that SAREF/SAREF4ENER is suitable to be used 
as  the overarching ontology for  DSF  and could eventually be extended with  missing concepts  from 
the CIM.  

Gaps 

The alignment shown in Figure 4-3 is only an initial step towards the harmonization of the CIM and 
SAREF/  SAREF4ENER.  However,  further  investigation  to  explore  potential  gaps,  i.e.,  missing  data 
elements or differences in meaning, is needed (see core concepts in red in the figure). For example, it 
has  to  be  clarified  whether  the  “State”  concept  in  SAREF  has  the  same  meaning  of  the  “Status” 
concept in CIM. The automatic alignment also suggests a matching in SAREF/ SAREF4ENER and CIM 
on the Load and Switch core concepts, but it has to be checked whether the meaning is the same and 
if the detailed data elements in CIM related to these core concepts are sufficiently covered by SAREF/ 
SAREF4ENER.  Although  there  is  an  exact  linguistic  match  between  saref:Profile  and  CIM:Profile, 
further investigation is necessary to clarify whether the meaning of “Profile” in the two standards is 
equivalent. Moreover, the concepts of “Property” and “Service” seem to have a different meaning in 

Digital 
Single 
Market 

 
 
 
the  two  standards.  Finally,  SAREF/SAREF4ENER  appear  to  be  underspecified  when  it  comes  to  the 
concepts of “Generator”.  

Actions 

The IEC CIM model is specified as UML class diagram, whereas more and more information models 
nowadays are published in the OWL format, which provides a formal representation of the semantics 
underlying the model and allows automated reasoning with dedicated software. An official IEC TC 57 
ontology  of  the  entire  IEC  CIM  model  published  in  the  OWL  format  does  not  exist,  or  it  should  be 
created using the CIM tool (http://wiki.cimtool.org/index.html), which appears not to be maintained 
anymore  by  the  CIM  community.  As  a  result,  the  burden  of  the  translation  from  UML  to  OWL  is 
currently left to the CIM users, who generate different OWL versions of the CIM, depending on how 
the  translation  UML  to  OWL  is  implemented  by  different  individuals.  An  example  of  a  CIM  profile 
generated from UML to OWL using the CIM tool in the context of the CERISE project38 is available at 
http://ontology.tno.nl/cerise/cim-profile/.  

Action owner 

Action 

A-8 

IEC TC 57 

Publish an official, standard OWL version of the CIM, as at the 
moment the burden of the translation from UML to OWL is left to 
the users (e.g., using the CIM tool), who generate different 
versions depending on how the translation is implemented. This 
also hinders the task to provide a standard alignment with other 
standards for DSF, like SAREF/SAREF4ENER.  

It is important for IEC TC 57 to be aware of the European effort in developing, maintaining and 
evolving the SAREF series of ontologies.  

Action owner 

Action 

A-9 

IEC TC 57 

When an official OWL version of CIM is developed for the purpose 
of DSF, IEC TC 57 should use the SAREF series of ontologies 
(especially SAREF4ENER) as input. The alignment proposed in this 
study (see Figure 4-3), together with the domain expertise coming 
from IEC TC 57 (for CIM) and ETSI SmartM2M TC (for SAREF4ENER) 
could be beneficial for the suggested task. 

4.3.5  Alignment and Actions for CENELEC EN 50491-11 Smart Metering 

Input for Alignment 

The EN 50491-11 standard specifies a data model to abstract the metering world towards a simple 
external consumer display. The data model, as described by means of functional blocks contained in 
EN  50491-11,  lays  down  the  format  of  metering  data  accessible  by  a  simple  external  consumer 
display. The EN 50491-11 standard does not specify the communication protocol used between the 

38 CERISE project: Combining Energy and Spatial Information Standards as Enabler for Smart Grids 
(http://www.cerise-project.nl).  

Digital 
Single 
Market 

 
 
 
 
 
 
                                                            
meters and the meter communication functions, but considers the EN 62056 COSEM series for the 
definition of the data model.  

Earlier alignments 

We  acknowledge  that  current  work  within  CLC/TC  205  aims  at  extending  the  EN  50491-11  Smart 
Metering standard with the mapping to COSEM.  

Analysis 

The mapping between the EN 50491-11 Smart Metering standard and IEC 62056 COSEM is already 
taken  care  of  by  an  ongoing initiative.  As  it is  out of  scope to  duplicate  efforts  already  being  done 
elsewhere,  we  did  not  identify  the  immediate  need  of  an  additional  mapping  of  the  EN  50491-11 
Smart  Metering  to  SAREF/  SAREF4ENER  (the  mapping  can  be  realized  at  the  moment  via 
DLMS/COSEM, which is aligned to both the EN 50491-11 Smart Metering and SAREF/SAREF4ENER).  

Gaps 

There are no gaps identified. 

Actions  

For  the  scope  of  this  study,  it  is  sufficient  that  there  are  ongoing  efforts  addressing  the  mapping 
between the EN 50491-11 Smart Metering standard and IEC 62056 COSEM. We observe that it may 
be  worthwhile  in  the  future  to  further  look  at  the  direct  mapping  of  EN  50491-11  Smart  Metering 
standard with SAREF/SAREF4ENER. 

Action owners 

Action 

A-10 

CLC/TC 205 

EN  50491-11  is  aligned  with  SAREF/SAREF4ENER  through  COSEM, 
meaning  that  interoperability  is  possible.  CLC/TC  205  should 
is  sufficiently 
consider 
practicable.  Otherwise,  direct  alignment  with  SAREF/SAREF4ENER 
could be explored. 

through  COSEM 

interoperability 

if 

Please note that Action A-3 specified in Section 4.3.1 also applies to EN 50491-11 Smart Metering. 

4.3.6  Alignment and Actions for CENELEC EN 50631-1 (SPINE) 

Input for Alignment 

The  data  model  in  the  prEN  50631-1  draft  standardized  by  CLC  TC59  WG7  is  based  on  the  “Smart 
Premises Interoperable Neutral-Message Exchange (SPINE)” specification created and maintained by 
EEBUS  in  collaboration  with  Energy@home.  For  the  alignment,  we  used  the  SPINE  specification 
available for download at https://www.eebus.org/en/downloads/. 

Earlier alignments 

explained 

As 
at 
410-1 
http://www.etsi.org/deliver/etsi_ts/103400_103499/10341001/01.01.01_60/ts_10341001v010101p.

SAREF4ENER 

(available 

V1.1.1 

ETSI 

103 

TS 

in 

Digital 
Single 
Market 

 
 
 
 
 
 
pdf),  SAREF4ENER  is  an  extension  of  SAREF  that  was  created  in  collaboration  with  EEBUS  and 
Energy@home  to  enable  the 
interconnection  of  their  (different)  data  models.  By  design, 
SAREF4ENER  is  fully  aligned  with  SPINE.  Therefore,  also  the  CENELEC  EN  50631-1  that  is  based  on 
SPINE  is  fully  aligned  with  SAREF4ENER.  The  main  concepts  aligned  in  both  the  SAREF4ENER  and 
CENELEC EN 50631-1/SPINE specifications are the following:   

  Device (e.g., appliance, meter, sensor, actuator, switch), Energy (e.g., EnergyMax, 

EnergyMin),  

  Power (e.g., PowerMax, PowerMin),  
  Time (e.g., StartTime, EndTime),  
  Duration (e.g., SlotTimeDurationDescription),  
  Power Profile,  
  Alternatives Group,  
  Power Sequence and  
  Slot  
 

Load Control information (i.e., LoadControlEventData, LoadControlEventActionConsume, 
LoadControlEventActionProduce, LoadControlStateData, LoadControlStateConsume, 
LoadControlStateProduce).  

Analysis 

For  details  on  the  approach  followed  to  reach  alignment  of  SAREF4ENER  and  SPINE  by  design,  see 
Annex A of  ETSI TS 103 410-1 SAREF4ENER V1.1.1.  

Gaps 

There are currently no gaps.  

Actions 

Since SAREF4ENER is already aligned by design to SPINE, no further action is suggested. The following 
observation could be however taken into account for the evolution of the alignment between SPINE 
and  SAREF4ENER.  Currently,  SAREF4ENER  defines  static information on  classes  and  properties,  and 
axioms  that  constrain  the  usage  of  these  classes  and  properties.  A  behavioural  part  that  specifies 
assertions  and  inferences  that  can  be  used  in  more  sophisticated  reasoning  mechanisms  (e.g.,  in 
terms of rules, if this, then that) has not been formalized yet. In SPINE, this behavioural part is only 
textually specified in the document, but no formal specification is provided. Future work could aim to 
add such a behavioural part/rules, possibly at the level of SAREF using e.g., an associated (standard) 
rule language like the W3C SHACL39 (from the same family of the RDF/OWL language commonly used 
for modelling ontologies).  

4.3.7  Alignment and Actions for CENELEC EN 50090 (KNX) 

Input for Alignment 

KNX IoT Ontology available at https://knxiot.org (access to the KNX ontology requires credentials that 
can  be  obtained  contacting  the  KNX  association).  KNX  Demand  Side  Management  white  paper, 

39 W3C SHACL 

Digital 
Single 
Market 

 
 
 
                                                            
version 2, November 2013, available at https://www.knx.org/media/docs/Flyers/KNX-Demand-Side-
Management-White-Paper/KNX-Demand-Side-Management-White-Paper.pdf. 

Earlier alignments 

The  “KNX  System  Specifications  Interworking  Datapoint  Types,  Version  01.09.01,  18  September 
2014”  document  has  been  used  as  basis  to  create  SAREF  in  the  previous  study  for  the  European 
Commission on “Semantic Assets for Smart Appliances Interoperability” [4]. Therefore, an alignment 
of  the  CEN  EN  50090  series  with  SAREF  already  exists  via  the  mapping  of  the  KNX  onto  SAREF 
performed in [4], which was based on the following KNX data elements: 

  Devices  that  can  be  configured  in  KNX  at  design-time.  Type  of  devices  include  Lighting, 
Blinds  &  Shutters,  Security  Systems,  Energy  Management,  Heating  Ventilation  and  Air-
Conditioning 
(HVAC)  Systems,  Monitoring  Systems,  Remote  Control,  Metering, 
Audio/Video Controls, and White Goods. 

  Datapoints  are  parameters  that  can  be  used  at  run-time  in  KNX  to  define  commands. 
Several  types  of  Datapoints  were  considered  as  basis  to  create  SAREF  (e.g.,  Datapoint 
Types for common use, Datapoint Types for HVAC, Datapoint Types for Load Management, 
Datapoint Types for Lighting, Datapoint Types for Systems). 

  Functional  Blocks  are  combinations  of  Datapoint  types  into  a  device.  Functional  blocks 
used  as  basis  to  create SAREF  were  Dimmer  Actuator  Basic and  Sunblind Actuator  Basic. 
For example, Dimmer Actuator Basic combines the DPT_ControlDimming, DPT_Scaling and 
DPT_Switch  data  point  types.  This  functional  block  can  be  in  one  of  the  3  states  “On”, 
“Off”,  or  “Dimming”,  which are  defined  under  the  DimmingActuatorBasicState class. The 
change  from  one  state  to  another  is  triggered  by  the  so-called  Events  with  one  of  the 
values listed under the  DimmingActuatorBasicEvent class. 

Analysis 

A  further  alignment  was  performed  in  this  study  to  determine  correspondences  and/or  gaps 
between  the  CEN  EN  50090  series  (KNX)  and  SAREF/  SAREF4ENER40  data  elements,  especially 
regarding DSF and use cases for demand response. We performed the alignment automatically (see 
approach  in  Section  4.2)  with  our  algorithm  for  ontology  matching  using  as  basis  the  KNX  IoT 
Ontology available at https://knxiot.org (access to the KNX ontology requires credentials that can be 
obtained  contacting  the  KNX  association)  and  the  SAREF/  SAREF4ENER  ontologies  available  at 
http://ontology.tno.nl. The resulting alignment is shown in Figure 4-4, where the core data elements 
in the middle are coloured in green to show sufficient overlapping, or in red when there is a possible 
gap and a consequent need for further action.  

As  is  shown  in  Figure  4-4,  there  is  a  potential  level  of  alignment  (see  common  data  elements  in 
green) on the following concepts:  

  Building. A class to describe in which part of the building a device is located. Covered by both 
the KNX ontology and SAREF. In particular, KNX specifies concepts such as knx:Building and 
knx:BuildingPart,  which  are  subclasses  of  knx:Space  and  can  be  related  to  knx:SpaceUsage 

40 Note that the alignment performed in [4] was between KNX and SAREF, while the current alignment considers 
also SAREF4ENER for demand response use cases, which did not exist yet at the time of the first study in [4].  

Digital 
Single 
Market 

 
 
 
                                                            
(e.g., Bedroom, Diningroom, Office, Garage, etc.). Note that the building spatial concepts are 
not covered by SAREF itself (and therefore they do not appear in Figure 4-4), but are covered 
by the extension SAREF for building (called SAREF4BLDG)41, which defines concepts such as 
s4bldg:Building,  s4bldg:BuildingSpace  and  s4bldg:BuildingObject  which  are  in  line  with  the 
KNX concepts for building. 

  Temperature.  Both  KNX  ontology  and  SAREF  provide  classes  to  express  temperature  and 

setpoint temperature with their value and corresponding unit of measure. 

  Time.  KNX  provides  several  Datapoints  (DPT)  to  express  Time.  Covered  also  by  SAREF 
(saref:Time 
ontology 
to 
(https://www.w3.org/TR/owl-time/)  to  further  specifies  time  related  concepts,  such  as 
time:TemporalEntity, time:Instant and time:Interval.  

external  W3C 

class)  which 

refers 

Time 

the 

  Pressure. Both KNX ontology and SAREF provide data elements to express pressure with its 
value and corresponding unit of measure (KNX in terms of datapoints and SAREF in terms of 
classes). 

  Switch. Both KNX ontology and SAREF provide data elements to define switch (whether it is a 

device or an action). 

  Actuator. Actuator data points in KNX ontology can be expressed with the Actuator class in 

SAREF. 

  Energy,  Electricity.  Covered  both  in  KNX  and  SAREF,  although  KNX  is  more  expressive 
concerning the Electrical-related data elements. Further investigation could address whether 
these elements need to have corresponding elements in SAREF. 

  HVAC. KNX has a large number of datapoints associated with HVAC. It may be worthwhile to 
further explore if SAREF is expressive enough to represent the KNX-information about HVAC. 
Load,  Control.  These  core  concepts  are  covered  both  in  KNX  and  SAREF,  although  with  a 
different level of detail. 

 

  Occupancy, Humidity. These data elements are covered in KNX and SAREF in a similar way. 

41 SAREF4BLDG is specified in ETSI TS 103 410-3 V1.1.1 (2017-01) and is available at 
http://www.etsi.org/deliver/etsi_ts/103400_103499/10341003/01.01.01_60/ts_10341003v010101p.pdf  

Digital 
Single 
Market 

 
 
 
                                                            
Figure 4-4:  Alignment of CEN EN 50090 (KNX) with SAREF/ SAREF4ENER using the algorithm for ontology matching 

Digital 
Single 
Market 

 
 
 
Gaps 

Figure  4-4  further  shows  that  there  are  some  potential  gaps  (see  common  data  elements  in  red) 
when it comes to the following concepts: 

  State.  KNX  ontology  presents  a  few  datapoints  to  express  “State”  and  many  datapoints  to 
express  “Status”  (18  types  of  different  datapoints  containing  the  string  “Status”  in  their 
name). Further investigation is needed to explore whether the Status datapoints in KNX are 
semantically  equivalent to  the State of  a  device  existing  in SAREF  and/or  whether  SAREF  is 
missing the concept of “Status” as intended by KNX. 

  Water. KNX presents some datapoints to express energy, power and temperature for water 
meters,  while  SAREF  is  underspecified  when  it  comes  to  water  meters.  A  possible  action 
could be needed to extend SAREF for water meters. 

  Power.  Both  KNX  and  SAREF  provide  means  to  express  power  usage  and  consumption. 
However,  it  seems  difficult  to  represent  the  important  SAREF4ENER  concepts  of  Power 
Profiles, Power Sequences and Slots using the existing KNX datapoints for Power.  

Actions 

Action owner 

Action 

A-11 

CLC/TC 205 

A-12 

CLC/TC 205 

Align the KNX ontology with SAREF/SAREF4ENER for the purpose of 
having only one ontology for interoperability (see elements in red 
in Figure 4-4). 

Since CENELEC EN 50090/KNX and CENELEC EN 50631-1/SPINE are 
both covered by CLC/TC 205 Home and Building Electronic Systems 
(HBES) and are both used for DSF, we suggest TC 205 to align these 
standards that cover the same interface (S2) to avoid confusion. 

As additional observation that involves CENELEC EN 50090/KNX, we acknowledge that TC 205 WG18 
is  planning  to  use  SPINE,  KNX  and  EFI  as  input  for  their  EN  50491-12-2  standard  regarding  the  S2 
interface (see section 3.3.3). However, this is work in progress and at the time of writing we cannot 
provide any official alignment of EN 50491-12-2 in relation to SAREF and SAREF4ENER.   

4.3.8  Alignment and Actions for oneM2M Base Ontology 

Input for Alignment 

The  latest  versions  of  the  Base  Ontology  specification,  TS  0012  Release  3  “Base  Ontology”  and  TS-
0030 "Ontology based Interworking", can be downloaded from http://onem2m.org/technical/latest-
drafts.  The  OWL 
found  at 
https://git.onem2m.org/MAS/BaseOntology. 

the  oneM2M  base  ontology  can  be 

representation  of 

Earlier alignments 

The ETSI TS 103 264 V2.1.1 contains the specification of SAREF 2.0 and a mapping to the oneM2M 
Base  Ontology  developed  in  collaboration  with  oneM2M  experts.  Figure  4-5  shows  this  mapping. 
Relationships  based  on  owl:equivalentClass  and  owl:equivalentProperty  are  considered  to  link  the 

Digital 
Single 
Market 

 
 
 
 
key classes and object properties of SAREF and the oneM2M Base Ontology. These are needed to be 
able  to  apply  the  oneM2M  instantiation  rules  to  the  semantic  description  of  entities  that  are 
described according to SAREF. 

Figure 4-5:  Alignment of oneM2M Base Ontology with SAREF 

Table 4-2 shows which SAREF class is mapped to which oneM2M class (and vice-versa). As a result, all 
oneM2M instantiation rules defined for the oneM2M class can also be applied to the instance of the 
respective SAREF class, and oneM2M instances can be discovered from SAREF when querying for 
devices, functions, commands and services.   

Table 4-3: Alignment of oneM2M Base Ontology classes with SAREF classes 

SAREF 

Mapping 
owl:equivalentClass 
saref:Device 
owl:equivalentClass 
saref:Service  
owl:equivalentClass 
saref:Function 
saref:SensingFunction 
owl:equivalentClass 
saref:ActuatingFunction  owl:equivalentClass 
owl:equivalentClass 
saref:Command 

oneM2M  

oneM2M:Device 
oneM2M:Service 
oneM2M:Function 
oneM2M:MeasuringFunction 
oneM2M:ControllingFunction 
oneM2M:Command 

Table 4-3 shows which SAREF object property is mapped to which oneM2M object property. 

Table 4-4: Alignment of oneM2M Base Ontology properties with SAREF properties 

SAREF 

Mapping 

oneM2M  

Digital 
Single 
Market 

DevicehasServicehasFunctionOperationInputrefersToControllingFunctionconsistsOfOperationOutputOperationStatehasOperationStateInterworkedDeviceThinghasThingPropertyhasThingRelationThingPropertyis-ais-aVariableOutputDataPointis-ais-aFunctionServiceOperationhasOperationCommandhasCommandis-aAspectMetaDataAreaNetworkisPartOfhasOutputhasInputhasMetaDatadescribesis-aSimpleTypeVariableMeasuringFunctionInputDataPointexposesCommandis-aoneM2M Base OntologyGET_InputDataPointis-aSET_OutputDataPointVariableAspecthasOutputDataPointhasInputDataPointhasSubServicehasOutputDataPointis-ahasInputDataPointVariablehasSubStructureDeviceFunctionhasFunctionServiceoffersrepresentsCommandhasCommandSAREF OntologySensingFunctionMeteringFunctionActuatingFunctionis-aexposesFunctionequivalentClassequivalentClassconsistsOfMappingequivalentClassequivalentClassequivalentClassequivalentClass 
 
 
 
saref:offers 
saref:hasFunction  
saref:represents 
saref:hasCommand 
saref:consistsOf 

owl:equivalentProperty 
owl:equivalentProperty 
owl:equivalentProperty 
owl:equivalentProperty 
owl:equivalentProperty 

oneM2M:hasService 
oneM2M:hasFunction 
oneM2M:exposesFunction 
oneM2M:hasCommand 
oneM2M:consistsOf 

Analysis 

A further alignment was performed in this study to validate the existing mapping between oneM2M 
Base  Ontology  and  SAREF  using  our  algorithm  for  ontology  matching.  We  performed  this  mapping 
automatically  (see  approach  in  Section  4.2)  using  as  basis  the  oneM2M  Base  Ontology  in  Turtle 
format available at https://git.onem2m.org/MAS/BaseOntology and the SAREF ontology available at 
https://w3id.org/saref.  The  resulting  alignment  is  shown  in  Figure  4-6  and  can  be  summarized  as 
follows: 

four  types  of  Functions 

  Function.  Covered  by  both  SAREF  and  oneM2M  Base  Ontology  (saref:Function  and 
oneM2M:Function are equivalent classes). SAREF goes into a higher level of detail, defining 
also examples of functions, such as saref:OnOffFunction and saref:OpenCloseFunction. SAREF 
defines 
(i.e.,  saref:ActuatingFunction,  saref:EventFunction, 
saref:MeteringFunction,  saref:SensingFunction),  while  oneM2M  Base  Ontology  defines  two 
types  of  functions  (i.e.,  oneM2M:MeasuringFunction  and  oneM2M:ControllingFunction). 
There is an equivalence between 1) saref:SensingFunction and oneM2M:MeasuringFunction; 
and saref:ActuatingFunction 2) and oneM2M:ControllingFunction. No equivalent in oneM2M 
for saref:EventFunction and saref:MeteringFunction. 

  Command.  Covered  by  both  SAREF  and  oneM2M  Base  Ontology  (saref:Command  and 
oneM2M:Command are equivalent classes). SAREF goes into a higher level of detail, defining 
examples  of  commands,  such  as  saref:OnCommand  and  saref:OffCommand,  but  also 
commands  related  to  saref:MeteringFunction  (which  is  missing  in  oneM2M),  such  as 
saref:GetCurrentMeterValueCommand. 

  Device.  Covered  by  both  SAREF  and  oneM2M  Base  Ontology 

(saref:Device  and 
oneM2M:Device  are  equivalent  classes).  SAREF  goes  into  a  higher  level  of  detail,  defining 
examples of devices, such as saref:LighthingDevice. SAREF defines also other type of devices 
such  saref:Meter,  saref:Sensor,  saret:Actuator  etc.  that  do  not  appear  in  the  alignment 
because  of  a  limitation  of  the  algorithm  we  have  used,  which  is  a  string-comparison 
algorithm42.  

  Service.  Covered  by  both  SAREF  and  oneM2M  Base  Ontology  (saref:Device  and 

oneM2M:Device are equivalent classes). 

  State.  Valid  match  based  on  string  comparison,  but  discarded  by  domain  expert  because 
saref:State  and  oneM2M:OperationState  are  not  semantically  equivalent,  their  meaning  is 
different. 

  Network. Valid match based on string comparison, but discarded by domain expert because 
saref:Network and oneM2M:AreaNetwork are not semantically equivalent, their meaning is 
different. 

42

The class-name-similarity is calculated by the Python-module FuzzyWuzzy that comes with an out-of-the-box string-

comparison algorithm. This algorithm does not detect the string “device” in terms such as saref:Meter, saref:Sensor, 
saret:Actuator etc. and therefore those devices do not appear in the alignment. We made use of a manual step performed by 
domain experts to overcome this limitation and make sure that we did not overlook important matches. Future work aims at 
improving the alignment-application to detect semantically related terms, not merely string-based similarity.  

Digital 
Single 
Market 

 
 
 
                                                            
  Property. Valid match based on string comparison, but discarded by domain expert because 
saref:Property and oneM2M:ThingProperty are not semantically equivalent, their meaning is 
different. 

Figure 4-6:  Alignment of oneM2M Base Ontology with SAREF using the algorithm for ontology matching 

Gaps 

There are no gaps identified between the oneM2M ontology and SAREF. However, in order to better 
understand the use of SAREF/SAREF4ENER in combination with oneM2M resources, it is beneficial to 
show an example of the tree structure for a oneM2M resource that can be automatically generated 
given a semantic description according to of SAREF/SAREF4ENER43. The following tree structure 
shows a oneM2M resource representing a smart meter device, its status and measurements using 
SAREF/SAREF4ENER: 

  <oneM2M Application Entity Resource>  e.g., saref:Meter 

o  <oneM2M Container1> for dynamic data, e.g. the ON/OFF Status of the meter  

43 The example belongs to the demonstrator implemented in this study and described in Appendix C “Detailed 
description of the demonstrations” of this document. 

Digital 
Single 
Market 

 
 
 
                                                            
  <Content Instance1.1> for the data content, e.g., the value ON 
  <Content Instance1.2> for the data content, e.g., the value OFF 
  <Content Instance1.3> for the data content, e.g., the value ON 
  … 
  <Semantic Descriptor1> static data according to the oneM2M Base Ontology 

or other external ontologies, e.g., the following excerpt of SAREF/SAREF4ENER 
from the DSF demo at EUW2017: 
euw17demo:SmartMeter 
rdf:type s4ener:Device ; 
rdfs:label "Smart Meter"^^xsd:string ; 
saref:hasManufacturer " Kamstrup"^^xsd:string ; 
saref:hasModel "SM-AZ123456"^^xsd:string ; 
saref:hasDescription "Kamstrup Smart Power Meter"^^xsd:string ; . 
<Ontology Ref1> the reference to the ontology used in the semantic 
descriptor, e.g., the following URLs of SAREF and SAREF4ENER used in the 
excerpt above:  
saref: <https://w3id.org/saref> 
s4ener: <https://w3id.org/saref4ener> 

 

o  <oneM2M Container2> for storing dynamic data, e.g. Power measurement 

  <Content Instance2.1> for the data content, e.g., the value 0.2 
  <Content Instance2.2> for the data content, e.g., the value 0.5 
  … 
  <Semantic Descriptor2> static data according to the oneM2M Base Ontology 
or other external ontologies, e.g., the following SAREF/SAREF4ENER excerpt 
from the DSF demo at EUW2017: 
euw17demo:Measurement_1 
rdf:type saref:Measurement ; 
saref:isMeasuredIn <http://www.wurvoc.org/vocabularies/om-
1.8/kilowatt> ; 
saref:relatesToProperty euw17demo:Power_1 ; .  

euw17demo:Power_1 
rdf:type s4ener:Power ; 
saref:isMeasuredByDevice euw17demo:SmartMeter; 
saref:relatesToMeasurement euw17demo:Measurement_1 ; . 
<Ontology Ref2> the reference to the ontology used in the descriptor, e.g., 
the following URLs of SAREF and SAREF4ENER used in the excerpt above:  
saref: <https://w3id.org/saref> 
s4ener: <https://w3id.org/saref4ener> 

 

Actions 

No  further actions  are  needed  at  a  semantic level,  as  considerable work  has  already  been done  to 
align SAREF and the oneM2M Base Ontology by the corresponding Technical Committees in ETSI and 
oneM2M (the resulting alignment of data elements is shown in  Table 4-2 and Table 4-3). However, 
we noticed a lack of guidelines and practical examples on how to implement oneM2M resources in 
the  oneM2M  Service  Layer  using  semantic  descriptions  according  to  SAREF  and  its  extensions.  In 
other words, an action is needed to create reproducible proof-of-concept solutions for stakeholders 
interested  to  use  SAREF  and  its  extensions  (at  a  semantic  level)  in  combination  with  oneM2M 
resources (at an architectural and protocol level).  An example solution is presented in the “Appendix 
C - Detailed description of the demonstrations” of this report, where a Sierra Wireless M2M platform 

Digital 
Single 
Market 

 
 
 
 
 
 
 
serves as a Flexibility Control System for an Energy Services company, combining data represented by 
oneM2M  resources  (on  the  WAN  side)  with  data  represented  by  SPINE  resources  (on  the  Smart 
Home side) using SAREF/ SAREF4ENER as overarching ontology. 

Action owner 

Action 

A-13 

oneM2M  and  ETSI 
SmartM2M 

Create  and  document  reproducible  examples/guidelines 
for 
semantic interoperability to be used by stakeholders interested to 
combine  SAREF  and  its  extensions  (at  a  semantic  level)  with 
oneM2M resources (at an architectural and protocol level).  

4.4  Results  
The objective of task 4 was to analyse the current semantic interoperability between the short-listed 
standards and define actions for alignment. The result of the analysis is shown in the table below. 

Table 4-5: Level of alignment 

STANDARD 

LEVEL OF ALIGNMENT 

EN 50631-1 (SPINE) 

Fully aligned with SAREF4ENER 

oneM2M Base ontology 

Fully aligned with SAREF 

IEC/CENELEC 62056 COSEM and  

Fair alignment with SAREF/SAREF4ENER 

CEN 16836 (ZigBee SEP2) 

Fair alignment with SAREF/SAREF4ENER 

CENELEC EN 50090 (KNX) 

Potential alignment with SAREF/SAREF4ENER 

IEC 61970 CIM 

Potential alignment with SAREF/SAREF4ENER 

CENELEC EN 50491-11 Smart Metering 

Aligned with IEC/CENELEC 62056 COSEM 

IEC 61968-9 CIM for Metering 

Aligned with IEC/CENELEC 62056 COSEM 

Full alignment between the selected standards can be achieved, executing the actions as defined in 
the table below. 

Action owners 

Action 

A-1 

CLC/TC 294 

Include Power Profile and associated concepts (i.e., Power Profile 
Alternatives Group, Power Sequence, Slot and corresponding 
attributes) in CEN EN 16836 (ZigBee SEP2). Or, explicitly 
acknowledge if these concepts are out of scope of CEN EN 16836 
(ZigBee SEP2) and provide explicit indication of which other 
international standard should be used to cover these missing 
concepts. 

Digital 
Single 
Market 

 
 
 
 
 
 
A-2 

ETSI SmartM2M TC 

A-3 

CLC/TC 294, CLC/TC 
205 and IEC/CLC/TC 
13 WG 14 

A-4 

ETSI SmartM2M TC 

A-5 

ETSI SmartM2M TC 

A-6 

IEC/ CENELEC TC 13 
WG 14, but also 
SAREF users in 
general 

Consider the possibility to explicitly extend SAREF to cover 
additional type of meters and related measurements (e.g., gas, 
water, heat, etc.) other than electricity meters, if relevant. 

There are various smart meter standards used for the same 
interface (H1/H2), i.e., CEN EN 16836 (ZigBee SEP2), CENELEC EN 
50491-11 Smart Metering, and IEC 62056 COSEM. Investigate 
overlapping between these standards, provide mappings and 
reduce duplication of work and efforts in different Technical 
Committees. 

Consider to extend SAREF to fill the identified gaps with IEC 62056 
COSEM (see red elements in Table 4-2), if relevant. These gaps 
concern the status of the meter reading (intended as quality of the 
reading), and specific parameters related to Gas, Water and Heat 
meters, such as Volume.  

Consider to explicitly extend SAREF to cover additional type of 
meters and related measurements (e.g., gas, water, heat, etc.) 
other than electricity meters. SAREF already provides the capability 
to derive other type of meters from existing classes. For example, 
new subclasses such as “Gas Meter” and “Water Meter” can be 
created from the existing “saref:Meter” class and associated with 
the already existing commodity types “saref:Gas” and 
“saref:Water”. The suggested classes could be created either as 
part of the SAREF core ontology or the already existing 
SAREF4ENER. Another option could be to start a new extension of 
SAREF explicitly dedicated to the Smart Metering domain, if 
relevant.  

When ad-hoc adjustments on SAREF/SAREF4ENER need to be done 
on a regular basis in different projects (recurrent adjustments), 
consider to submit a request to ETSI SmartM2M TC, so that an 
updated version of SAREF that incorporates these adjustments 
could possibly be released. For example, if one has to define 
recurrently in their own projects a “myproject:ReactivePower” 
instance from the existing “saref:Power” class, it would be 
beneficial to provide feedback to ETSI SmartM2M TC44, requesting 
to create a class “saref:ReactivePower” (instead of having to define 
a “myproject:ReactivePower” instance over and over in different 
projects). 

A-7 

IEC TC 13 and IEC TC 

CIM for metering is aligned with SAREF/SAREF4ENER through 
COSEM, meaning that interoperability is possible. IEC TC 13 and IEC 

44 All ETSI members can participate to SmartM2M TC meetings (usually held four times per year) and ad-hoc 
calls on SAREF related topics, to provide feedback on the use and evolution of SAREF. Contacts of the 
SmartM2M TC Officials and the schedule of the meetings can be found at https://portal.etsi.org/home.aspx  

Digital 
Single 
Market 

 
 
                                                            
57 

TC 57 should consider if interoperability through COSEM is 
sufficiently practicable. Otherwise, direct alignment with 
SAREF/SAREF4ENER could be explored. 

A-8 

IEC TC 57 

A-9 

IEC TC 57 

A-10 

CLC/TC 205 

A-11 

CLC/TC 205 

A-12 

CLC/TC 205 

A-13 

oneM2M and ETSI 
SmartM2M 

Publish an official, standard OWL version of the CIM, as at the 
moment the burden of the translation from UML to OWL is left to 
the users (e.g., using the CIM tool), who generate different 
versions depending on how the translation is implemented. This 
also hinders the task to provide a standard alignment with other 
standards for DSF, like SAREF/SAREF4ENER.  

When an official OWL version of CIM is developed for the purpose 
of DSF, IEC TC 57 should use the SAREF series of ontologies 
(especially SAREF4ENER) as input. The alignment proposed in this 
study (see Figure 4-3), together with the domain expertise coming 
from IEC TC 57 (for CIM) and SmartM2M TC (for SAREF4ENER) 
could be beneficial for the suggested task. 

EN 50491-11 is aligned with SAREF/SAREF4ENER through COSEM, 
meaning that interoperability is possible. CLC/TC 205 should 
consider if interoperability through COSEM is sufficiently 
practicable. Otherwise, direct alignment with SAREF/SAREF4ENER 
could be explored. 

Align the KNX ontology with SAREF/SAREF4ENER for the purpose of 
having only one ontology for interoperability (see elements in red 
in Figure 4-4). 

Since CENELEC EN 50090/KNX and CENELEC EN 50631-1/SPINE are 
both covered by CLC/TC 205 Home and Building Electronic Systems 
(HBES) and are both used for DSF, we suggest TC 205 to align these 
standards that cover the same interface (S2) in order to avoid 
confusion. 

Create and document reproducible examples/guidelines for 
semantic interoperability to be used by stakeholders interested to 
combine SAREF (at a semantic level) with oneM2M resources (at 
an architectural and protocol level). 

Digital 
Single 
Market 

 
 
 
 
 
5. Conclusions and recommendations 
The  main  conclusion  is  that  interoperability  between  the  selected  standards  can  be  achieved, 
however, action is required to achieve it.  

An  important  conclusion  is  that  the  SAREF  and  SAREF4ENER  ontologies  can  be  used  as  the 
overarching ontologies to make alignments between standards. If all standards can be aligned with 
SAREF/SAREF4ENER  on  the  core  data  elements  in  the  DSF  domain,  then  all  standards  are  also 
semantically interoperable with each other. 

A  certain  level  of  alignment  already  exists.  Out  of  the  eight  standards  that  have  been  analysed  on 
alignment  with  SAREF/SAREF4ENER,  two  standards  are  fully  aligned  and  do  not  need  any  further 
action for alignment. The first one is SPINE, which is aligned with SAREF/SAREF4Ener by design. The 
other one is oneM2M, for which good work has already been done by the Technical Committees in 
ETSI and oneM2M. 

Four  standards  need  further  alignment,  for  which  actions  are  defined,  these  standards  are: 
IEC/CENELEC 62056 COSEM, CEN 16836 (ZigBee SEP2), CENELEC EN 50090 (KNX) and IEC 61970 CIM. 
For the specific actions, we refer to the results section of chapter four. 

The remaining two standards, CENELEC EN 50491-11 and IEC IEC 61968-9 CIM for Metering, do not 
have a direct alignment with SAREF/SAREF4ENER, but are aligned through  the COSEM standard, as 
they all cover the same interface. Therefore, these standards are considered to be aligned, however, 
in  the  future  it  might  be  more  practical  when  these  standards  have  a  direct  alignment  with 
SAREF/SAREF4ENER.  

The  demonstrations  that  have  been  performed  in  this  study  (Amsterdam,  Brussels  and  Sophia 
Antipolis) have shown that for a subset of standards (oneM2M, COSEM and SPINE) interoperability is 
achieved  using  SAREF/SAREF4ENER.  For  more  detailed  and  practical  conclusions  we  refer  to  the 
detailed descriptions in Appendix C.  

Additional  to  the  actions  that  have  been  defined  to  reach  alignment  between  standards,  we  have 
defined several recommendations that smooth the road to interoperability: 

I. 

II. 

The study has shown that SAREF/SAREF4ENER can be used to reach interoperability on data 
level. We therefore recommend that SAREF4ENER is used as the ontology for the interfaces 
that are relevant for DSF applications as indicated in this report (H1, H2, S1, S2, G3). 

Since  the  development  of  ontologies  is  taking  place  in  several  organisations  and  even  in 
several committees within the same SDO, we recommend that SAREF4 ENER is promoted as 
the  ontology  for  Demand  Side  Flexibility  system  components,  in  order  to  prevent  the 
development of competing solutions. 

III.  We recommend the European SDO’s to join forces and upgrade SAREF (or elements of it) to a 

“Three logo Standard” (i.e., a CEN, CENELEC and ETSI standard). 

IV. 

It is recommended that a ‘power limitation’ use case is developed in which the following data 
elements are incorporated: power limit and actual power consumption. Analyses the DSF use 
cases  in  task  1  showed  that  no  use  case  was  identified  that  covered  the  case  in  which  the 

Digital 
Single 
Market 

 
 
 
 
 
Smart Meter informs the CEM about the programmed power limit and the actual total power 
that is consumed. A common Smart Meter use case is ‘power limitation’.  

V. 

A  common  format  of  presenting  use  cases  in  documents  published  by  the  SDO’s  is 
recommended. Although this format is existing (i.e., IEC 62559), many Use Cases identified in 
this project do not use that format. 

Overall, we conclude that alignment between standards is needed and that SAREF/SAREF4ENER can 
be used as the overarching ontology to facilitate alignments. Several actions and recommendations 
for various stakeholders, such as the Standards Development Organisations, have been identified and 
are  listed  in  the  report.  The  next  step  to  be  taken  is  scaling  up  the  proof  of  concept  that  we 
demonstrated.  The  SAREF  ontology  needs  to  be  implemented  in  more  use  cases  for  Demand  Side 
Flexibility, in more smart devices and at real consumer sites.  

Digital 
Single 
Market 

 
 
 
 
 
References 

[1]  Explicit and Implicit Demand-Side Flexibility, Complementary Approaches for an Efficient Energy 

System, SEDC, September 2016. 

[2]  USEF, the framework explained, USEF, Nov 2015. 

[3]  USEF, the framework specifications, USEF, Nov 2015 

[4]  Laura Daniele, Frank den Hartog and Jasper Roes: Study on Semantic Assets for Smart Appliances 

Interoperability, D-S4 Final Report. Brussels: European Commission, March 2015. 

[5]  EICTA Interoperability White Paper, European Industry Association, Information Systems 

Communication Technologies Consumer Electronics, 21 June 2004 

[6]  AIOTI WG03- IoT Standardisation:  IoT LSP Standard Framework Concept 2.0 (2015)  

[7]  AIOTI WG03- IoT Standardisation: IoT Semantic Interoperability 2.0 (2015) 

[8]  Jérôme Euzenat and Pavel Shvaiko: Ontology matching, Springer-Verlag (2007), 978-3-540-

49611-3 

[9]  Vladimir I. Levenshtein, Binary codes capable of correcting deletions, insertions, and reversals, 

Soviet Physics Doklady, 10(8):707-710 (1966). 

 
 
 
 
 
 
 
Appendix A - Longlist of Use Cases 

Use cases presented in IEC62746-2:2015 

Section in 
IEC62746-
2:2015 

A.3.2 

A.3.3 

A.3.4  

A.3.5 

A.3.6 

A.3.7 

A.3.8 

A.3.9 

A.3.10 

A.3.11 

Use case name: 

Selected: 

Comment: 

The use cases A3.2-A3.6 are important 
because they relate to Smart Devices 
that have flex capabilities that can be 
used by Actor A via the CEM. Not all 
individual use cases cover multiple 
interfaces, however, several use cases 
can be combined to a more 
sophisticated one that covers multiple 
interfaces in the architecture. 

Describes how non-smart controller 
can be operated smart. Involves 
multiple interfaces & data elements. 
Same case as A3.8-JWG1124 but with 
different type of controller. 

Describes how non-smart controller 
can be operated smart. Involves 
multiple interfaces & data elements 

No smart device involved, focuses on 
local generation. 

No smart appliances involved, 
focusses on load/generation. 

No smart appliances involved, 
focusses on load/generation. 

Flexible start of a SD. 
(JWG1100) 

SD informs CEM about 
flexible start 
(JWG1101) 

CEM informs SD about 
starting time. (JWG-
SPUC1102) 

CEM informs SD about 
slot shift. (JWG1103) 

Control of Smart home 
appliances based on 
price information by 
time slot. (JWG1110) 

Fuel Cell Operation 
with Fixed Tariff Profile 
(JWG1111) 

Manage Mixed Energy 
System like heat 
pumps with PV, 
Storage Battery. 
(JWG1124) 

Log Mixed Energy 
System events of heat 
pumps with PV, 
Storage Battery. 
(JWG113x) 

Provide local power 
managing capabilities. 
(JWG120x) 

Provide local power 
managing capabilities. 
(JWG121x) 

Yes: UC2 

Yes: UC2 

Yes: UC2 

Yes: UC2 

Yes: UC2 

Yes: UC4 

Yes: UC4  

No. 

No. 

No. 

Digital 
Single 
Market 

 
 
 
 
 
 
 
 
 
 
 
 
In this use case, multiple interfaces 
are covered and smart devices 
exchange information with actor A via 
the CEM. It’s an essential use case. 

Special case for buildings, not 
important for this study. Study 
focuses on smart homes. 

Special case about multiple building in 
district, not important for this study. 

Less important for this study, is about 
grid management instead of DSF 

Less important for this study, is about 
grid management instead of DSF. 

Less important for this study, is about 
grid management instead of DSF. 

Not important for this study, special 
case. 

Covers total infra and relevant data is 
exchanged over multiple interfaces. 

Refers to the same set of WGSP’s as 
A3.19 

A.3.12 

A.3.13 

A.3.14 

A.3.15 

A.3.16 

A.3.17 

A.3.18 

A.3.19 

A.3.20 

Demand Supply 
Adjustment by 
cooperation between 
supplier and customer. 
(JWG2000) 

Cascaded CEM 
(JWG2001) 

District Energy 
Management 
(JWG2002) 

Information exchange 
on distributed power 
systems with RES 
(JWG2010) 

Peak Shift Contribution 
by Battery Aggregation 
(JWG202x) 

Power Adjustment 
Normal Conditions 

(JWG2041) 

Energy 
Accommodation for 
Buildings Under 
Disaster Conditions 

(JWG2042) 

Tariff-Consumption 
Information Exchange  
(WGSP2111) 
(WGSP2114) 

Exchanging 
information on 
consumption, price, 
device status and 
warnings with external 
actors and within the 
home 

(WGSP2111) 
(WGSP2114) 

Yes: UC6 

No. 

No. 

No.  

No. 

No. 

No. 

Yes: UC7 
(Price, 
consumptio
n)  

Yes: UC8 
(Status, 
warnings) 

Yes: UC7 
(Price, 
consumptio
n) 
Yes: UC8 
(Price, 
consumptio
n) 

Digital 
Single 
Market 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
A.3.21 

A.3.22 

Direct Load-
Generation 
Management 
(International) 

Direct load / 
generation 
management 
(European) 

Yes: UC3 

Involves Smart Devices, covers total 
infrastructure. 

Yes: UC3  

Refers to the same set of JWG’s as A3.21. 

(WG 2122, scenario 1) 

A.3.23 

Tariff synchronization 

Yes: UC9  

(WG2141) – via time 

Yes: UC10  

(WG2143) – via tariff change 
notification. 

A.3.24 

A.3.25 

A.3.26 

A.3.27 

Energy Flexibility 
Management  

Energy 
production/storage 
integration 

Power loss notification 
and analysis 

Historical data 
visualization (external 
data processing & 
storage) 

No. 

No. 

No. 

No. 

Use Cases Presented in prEN 50631-1 

Covers multiple interfaces. Important 
use case about keeping time 
synchronicity between smart meter 
and CEM. 

This use case gives a very broad 
description and details are missing. 

No Smart Devices in the home 
involved. Use case is not about DSF. 

Special case, CEM with UPS 
capabilities.  Use case is not about 
DSF. 

Use case is about export of historical 
data from CEM to external, private 
server. Interface is not in scope of this 
study. 

Section in: 
prEN50631 

Description: 

Selected: 

Comment: 

5.3.4  

Flexible Start 

Yes: UC2 

5.3.5  

Direct Load control 

Yes: UC5 

Use case description is limited to the 
interface between CEM and SD. 
Description of use case is very limited, 
but it can be derived that it belongs to 
‘Flexible start’, UC2. 

Use case description is limited to the 
interface between CEM and SD. Direct 
control of load via CEM, so belongs to 
UC5. 

Digital 
Single 
Market 

 
 
 
 
 
 
 
 
 
 
 
5.3.6  

Emergency Blackout 
prevention 

Yes: UC3 

5.3.7  

Remote Programming 

Yes: UC1 

5.3.8  

Remote Monitoring 

Yes: UC8 

5.3.9  

Manual Operation 

No. 

5.3.10  

Install Smart Appliance 

Yes: UC1 

5.3.11  

Remove smart Appliance 

No. 

Use case description is limited to the 
interface between CEM and SD. 
Emergency signal is send from CEM to 
Smart Device, so belongs to UC3. 

Use case description is limited to the 
interface between CEM and SD. Belongs 
to configuration of the system, so 
related to UC1. 

Use case description is limited to the 
interface between CEM and SD. 
Monitoring of status belongs to UC9. 

No interfaces involved if smart device is 
in manual mode. 

Belongs to installation / configuration of 
the smart devices, so related to UC1. 

Removal of Smart Device from CEM. No 
identification data elements exchanged 
over the interface, so not relevant for 
this study. 

Digital 
Single 
Market 

 
 
 
 
 
Use Cases presented in ETSI TR 103 411 V1.1.1 (2017-02) 

Description: 

Selected: 

Comment: 

Use case in 
ETSI TR 103 
411 V1.1.1 
(2017-02), 
section 
5.1.1. 

From the description, it can be derived that 
this use case relates to UC1 (Installation 
and configuration). Use case gives high 
level description, without explicit 
mentioning the data elements between the 
actors. 

From the description, it can be derived that 
this use case relates to UC2 (Flexible Start). 
Use case gives high level description, 
without explicit mentioning the data 
elements between the actors. 

Use case 1. 

Configuration of devices. 

Yes: UC1 

Configuration of devices 
that want to connect to 
each other in the home 
network, for example, to 
register a new dishwasher 
to the list of devices 
managed by the CEM; 

Use case 2a. 

 Appliance scheduling. 

Yes: UC2 

CEM receives the input 
from the appliance that it is 
ready to start and in remote 
control OR that was 
manually planned to start. 
On UI the user can see 
tariffs for the day and areas 
of incentives for consuming 
/non consuming energy. 
User can plan when to start 
the appliance in remote 
control and see what other 
products are already 
running or planned to start. 

Use case 2b.  Automatic re-scheduling.  

Yes: UC2 

CEM receives the input 
from Utility/Aggregator that 
a more convenient time to 
run the appliance is 
available. On UI, user can 
see the new timing for the 
start of the dishwasher. 
Case can be played also 
with rescheduling to avoid 
peak hours. 

From the description, it can be derived that 
this use case relates to UC2 (Flexible Start). 
Use case gives high level description, 
without explicit mentioning the data 
elements between the actors. 

Use case 3:  Monitoring and Control 

Yes: UC5 

monitoring and control of 

From the description, it can be derived that 
this use case relates to UC5 (Direct Load 
control). Use case gives high level 

Digital 
Single 
Market 

 
 
 
 
description, without explicit mentioning the 
data elements between the actors. 

Yes: UC2 

From the description, it can be derived that 
this use case relates to UC2 (Flexible start): 
SD offers flexibility, and Utility utilizes this 
via CEM. Use case gives high level 
description, without explicit mentioning the 
data elements between the actors. 

Use case 4a 

the start and status of the 
appliances; 

CEM receives the input 
from Utility/Aggregator that 
a more convenient time to 
run the appliance is 
available.    
On UI, user can see the new 
timing for the start of the 
dishwasher.  
Case can be played also 
with rescheduling to avoid 
peak hours. 
Reaction to the Grid: 

CEM receives the input 
from Utility about incentive 
to consume more energy or 
reduce total consumption 
below a defined level. Some 
products that are not cycle 
based (Air Cond., Water 
Heater, etc.)  can modify 
their settings to fulfil the 
request. 
Appliances can increase or 
reduce power based on 
their capability and what 
they are doing. Notification 
is provided to the user 
through the UI. 

From the description, it can be derived that 
this use case relates to UC3 (Emergency). 
Use case gives high level description, 
without explicit mentioning the data 
elements between the actors. 

Use case 4b.  Reaction to the Grid:  

Yes: UC3 

CEM receives the input 
from Utility or smart meter 
that there is an emergency 
and that products are 
requested to reduce 
consumption for few 
minutes. 
Appliances reduce power 
based on their capability 
and what they are doing. 
Notification is provided to 
the user through the UI. 
Appliances that are planned 
to start a cycle during the 
critical time will be 
rescheduled. 

Digital 
Single 
Market 

 
 
 
 
 
Use Cases presented in IEC62913-2-3 CD: 2016 

Description: 

Selected: 

Comment:  

Reference to 
IEC62913-2-
3/CD: 2016 
Table 13  

System UC-1 

Configure the Smart Home 
to enable the 
interoperability with the 
Smart Grid. 

Yes: UC1 

System UC-2 

Manage the flexibility of the 
Smart Home on electricity 
demand and generation 
from prices incentives. 

Yes: UC2 

System UC-3 

Manage the flexibility of the 
Smart Home on electricity 
demand and generation 
from DR requests.  

Yes: UC5 

System UC-4 

Manage the flexibility of the 
Smart Home on electricity 
demand and generation 
from emergency signals  

Yes: UC3 

From the description, it is derived that 
this use case relates to UC1 (Installation 
and Configuration). Data elements are 
not mentioned. 

From the description, it is derived that 
this use case relates to UC2 (Flexible 
start of device). Data elements not 
explicitly mentioned. 

From the description, it is derived that 
this use case relates to UC5 (Direct Load 
control). Data elements are not explicitly 
mentioned. 

From the description, it is derived that 
this use case relates to UC3 (Response 
to Emergency). Data elements not 
explicitly mentioned. 

System UC-5 

System UC-6 

Manage opt-outs to 
automatic responses (only 
prices incentives and DR 
requests, emergency 
excluding) including manual 
actions  
Provide a third party with 
enriched Smart Home 
electricity data  

System UC-7 

System UC-8 

System UC-9 

Provide alarms related to 
the smart home electricity 
behaviour to the client or 
resident  
Customise automatic 
responses of the Smart 
Home (price incentives, DR 
requests, or emergency 
signals) of the Smart Home  
Process metering data to 
invoice electricity supply of 
the Smart Home  

No. 

Special case, not included. 

It is not defined what is exchanged over 
the interfaces and how this use case 
relates to DSF. It is a too high level 
description. No definition of information 
exchange. 

No definition of information exchange. 
No direct relation with DSF indicated. 

Relates to configuration of the Smart 
Devices in the Smart home. To high level 
description to derive data elements. 

This use case is about metering data, so 
it is not included. 

No. 

No. 

UC-1 

No. 

Digital 
Single 
Market 

 
 
 
System UC-10 

System UC-11 

Process data related to the 
Smart Home behaviour to 
aggregate (forecasting, real-
time), valuate and certify 
flexibilities  
Process metering data to 
remunerate electricity feed 
in by the Smart Home  

Y: UC6 

No. 

From the description, it can be derived 
that this use case relates to UC6. 

This use case is about metering data, so 
it is not included. 

Digital 
Single 
Market 

 
 
 
 
 
Appendix B - Workshop on interim results 

Objectives 

On June 19th 2017 a workshop was organized in Brussels. This event has been jointly organized by the 
European Commission and the consortium conducting the study on "Demand Side Flexibility (DSF) 
Interoperability" (SMART 2016/0082) by request of the European Commission as part of the tender 
specifications. The objectives of the workshop were: 

introduce the DSF study to the interested stakeholders and present its intermediate results; 

 
  discuss relevant developments in the field of ontology and data format standardisation 

 

related to DSF; 
collect feedback from stakeholders on the identified use cases and standards, the proposed 
approach and the expected outcomes. 

Participants 

There were 43 registered participants and 39 physical participants. The participants were coming 
from a variety of backgrounds (EU Commission, Industry, SDOs, Research and consumer 
organisations). In addition, a remote connection has been organized and 3 Participants have been 
following the workshop electronically (Hartwig Ziegler, Francisco da Silva, Enrico Scarrone). 

Contributions of the DSF Interoperability Team 

The whole DSF Interoperability study team has participated in preparing and conducting the 
workshop: Willem Strabbing (ESMIG), Arjan Aalberts (DNV GL, project leader), Laura Daniele (TNO), 
Paul Stapersma (TNO), Bas Roelofsen (DNV GL) and Hans de Heer (DNV GL). 

The morning session was fully dedicated to the presentation of the scope, objectives, approach and 
(intermediate) results of the DSF study, based on the work carried out in Tasks 1, 2 and 3. 

The afternoon session was devoted to the introduction by four key experts from EEBUS, CLC TC 205, 
ETSI SmartM2M TC and OneM2M to their current standardization activities, followed by an 
interactive Q&A session that involved most of the stakeholders in the audience. 

The presentations made during the Workshop are available on the DNV GL web site at: 
https://www.dnvgl.com/events/interoperability-for-demand-side-flexibility-93109. 

Morning session 

The morning session was fully dedicated to present the scope, objectives, approach and 
(intermediate) results of the DSF study, based on the work carried out in Tasks 1, 2 and 3. After 
presenting each task a short discussion/Q&A session took place. Below the highlights of those 
discussions. 

Task 1: 

During the discussion, a recommendation for Distribution System Operators (DSOs) was 
agreed on the use of the IEC template for use cases. In addition, it will be worth examining 

Digital 
Single 
Market 

 
 
the use cases that have been developed within H2020 / FP7 projects, by the smart appliances 
industry (EEbUS, energy@home) and the French National Committee. The team has decided  
to consider only the use cases  That contain new data elements, not yet found in the formal 
Use Cases from the official Standard Development Organisations. 

During the discussion, it was observed that the interface between the consumer, and either 
the CEM or the appliances, is not part of the scope. The project focusses on data definitions 
for M2M communication and it is expected that information provided by the consumer will 
result in M2M information flows from the appliance or CEM to other components of the 
infrastructure. 

Further, use cases targeting Electric Vehicles (EV) have not been considered, this may 
however be relevant with respect to local storage facilities. The project team has considered 
EV use cases as suggested by the participants of the workshop. However, the team has only 
considered use cases  that cover data exchange over multiple interfaces  of the 
infrastructure, and not just communication with the CEM for example.. Several EV use cases 
are still under development (eg in the EEbUS consortium).  

Task 2 and 3: 

An in-depth discussion took place on the follow-up on how to ensure that the 
recommendations of the project are being implemented by the SDOs. Moreover, it was 
discussed how the (modified) standards could be used in practice by the industry. Some 
thoughts on the required level of detail are shared, i.e., whether the data elements and their 
alignment should be done at a higher level of abstraction or at a very deep technical level, 
making very detailed alignments for all considered standards requires considerable resources 
which will not be possible in this project, but we will provide alignments on the most 
important data structures so that SDOs will be able follow up on the suggested actions. 

Afternoon session 

In the afternoon four experts from key standardization bodies were invited by the project team to 
share their views on the topic of DSF interoperability, focusing on the developments within their 
technical Committees and Working Groups: 

Presenter 1: Josef Baumeister;  

Josef discussed the EEBUS initiative for smart energy management. The main discussion was 
on the costs associated with using smart appliances based on EEBUS standards (i.e., SPINE), 
as well as on energy labels that could indicate whether appliances comply to specific 
requirements such as DSF standards (a.o. SAREF and SPINE). 

Presenter 2: Lee Gould;  

Lee discussed the development within CLC TC205. The main discussion was on the use of the 
SGAM model (Smart Grid Architectural Model, developed by the CEN/CENELEC/ETSI Smart 
Grid Coordination Group under Mandate 490), which provides a useful method to position 
standards within the DSF domain, and may help identifying missing or overlapping standards. 

Digital 
Single 
Market 

 
 
Presenter 3: Enrico Scarrone; 

Enrico presented the activities related to smart appliances and IoT standardization in the 
SmartM2M TC in ETSI. These activities mainly relate to the ontology framework for multiple 
domains based on SAREF, specified in 2015 and updated in 2016, integrated with the 
oneM2M based ontology. The main discussion was on the plans with respect to SmartM2M 
standardization. 

Presenter 4: Joerg Swetina; 

Joerg presented the oneM2M standard, a software/middleware layer, sitting between 
applications and underlying communication networking HW/SW, which exposes common set 
of functions to applications via REST API and is integrated into devices gateways & servers. 
The main discussion is on the relation of oneM2M to ISO work, especially on security aspects. 
Everybody agreed that the ISO work should not be neglected, especially with respect to 
security.  

Q&A session; 

After a summary of the main discussions and questions raised throughout the day, a Q&A session 
took place to further discuss the points that needed elaboration, and new questions could be raised. 
The main topics covered during the Q&A session were: 

  How will the recommendations be followed-up by the SDOs such as IEC, CEN, CENELEC, ETSI 

and oneM2M? 

  What can we do to move the (buying) industry to use/require the existing standards? 
  Ecodesign and labelling for “demand response ready” devices and appliances. 

Conclusions 

The participants have been very active in the presentations, as well as during the feedback and the 
Q&A session with many questions and points of view expressed. The project team perceived a 
consensus between the attendants on the proposed method for reaching semantic interoperability. 
The need to reach alignment between different standards was acknowledged several times during 
the day by the stakeholders. Specific input received: 

  The use of existing standards should be mandated on European or at least national level; 
  To give a good overview of existing standards, they should be linked with the interoperability 
levels on SGAM: to what level do they apply. The standards covered in this project apply to 
the information and function layers. 

Appendix C - Detailed description of the demonstrations 

C1. General description of the demonstrations 

Digital 
Single 
Market 

 
 
 
 
In total, there have been three demonstrations related to this project. The objective of these 
demonstrations is to show applications for Demand Side Flexibility (DSF) in practise and in an open 
and standards based infrastructure as shown in figures 1-1 and 2-1. 

SAREF was used in the demonstrations to facilitate the data integration that is originally modelled in 
standards produced by the metering industry in CENELEC TC13 (DLMS/COSEM) and the Home 
Automation industry EEbUS (SPINE). The communication with IoT platforms has been implemented 
through a combination of the SAREF ontology and oneM2M communication services. More details 
about the technical set-up can be found in section B2.  

The first demonstration took place at the European Utility Week conference and exhibition 3-5 
October 2017, where also the project itself was presented by ESMIG and TNO. In this demo the full 
scope of the DSF architecture as shown in figure 2-1. It comprised the following components: 

-  An IoT platform for the DSO, connected to a Head End System (HES) and Data Analytics 

application 
The HES connected to two smart meters 

- 
-  An IoT platform for the ESCO, connected to a Home Energy Gateway 
-  A smart meter connected to an In-Home Display and light bulb 
-  A smart meter connected to an In-Home Display and Home Energy Gateway 
- 
- 

Smart Appliances connected to the Home Energy Gateway through a CEM functionality. 
The smart appliances: a washing machine, a dryer, heat pump and EV charging station. 

The picture below shows the set-up. 

Figure 0-1: European Utility Week demonstration setup 

Please note that the CEM functionality is not separately shown in this picture, it is supposed to be 
included in the “bubble” Smart Appliances. 

Not all systems were physically present at the exhibition. The M2M-IoT platforms, HES and Data 
Analytics applications are reached through an internet connection to remote servers. 

The demonstration covered two main functions: 

1.  Collection and analysis of meter data 
2.  Management of consumption 

Digital 
Single 
Market 

 
 
 
Function 1. 

The meter data that is collected is provided by smart meters through two different interfaces on the 
meter. One (upstream) interface is used by the meter/grid operator for billing and grid management. 
This data is fed into the Head End system. Another interface provides real-time data for energy 
management. This data is fed into a Home Energy Gateway. 

Historic meter data can be retrieved from the Head-End system and this is done by the Telit IoT 
platform. Real-time data is retrieved by the Telit M2M platform from the Energy Gateway. 

The Watt-IS Data Analytics application analyses (real-time) consumer data to give insight in consumer 
behaviour and recommendations for energy efficiency. 

So, the Telit M2M platform serves as a Data Hub for a Metering Services company. 

Function 2. 

Basically, there are two ways for managing energy consumption. 

One is through the switch in the Smart Meter. This is an action that can be taken by a Grid Operator 
in case there is a risk that a black-out can occur caused by for example high consumption and low 
power generation capacity. This action will cause complete homes to be switched off. This is 
demonstrated by the meter connected with a light bulb. 

Another, more sophisticated way, to manage energy consumption is through control of individual 
smart appliances. An energy services company can, for example on request of a grid operator, issue a 
command to reduce energy consumption. The motivation for such a command can also be an 
economical one: use less energy when prices are high. The Consumer Energy Management system 
(CEM) decides what appliances will be switched or activated at what moment based on the status of 
appliances. A second smart meter is connected to the Home Energy Gateway providing real-time 
information for the CEM. 

The EMG and CEM can receive commands to increase consumption (for example when prices are 
low) or decrease consumption from the Sierra M2M platform.  

So, the Sierra M2M platform serves as a Flexibility Control System for an Energy Services 
company. 

A second demonstration took place in Sophia Antipolis during the ETSI IoT week 23-26 October 2017. 

Due to limited space, the physical set-up was limited as compared to the EUW demo, but the 
implementation of the combination of data standards (COSEM, SPINE), the ontology (SAREF) and 
oneM2M communication services was the same. The demonstration set-up is shown in the picture 
below. 

Digital 
Single 
Market 

 
 
 
Figure 0-2: Sophia demonstration setup 

As can be seen there was only one IoT platform and one Smart Meter in this demonstration. Since 
there was no space to install large small appliances, a washing machine was connected remotely and 
could be followed through a video connection. 

Also at the ETSI conference ESMIG and TNO presented the project. 

A third demonstration took place at DG-Connect’s premises in Brussels on 27, 28 and 29 November 
2017. This was again a full implementation of the DSF architecture like the EUW version. The number 
of smart appliances was however extended with a dish washer, tumble dryer and Solar power 
convertor station. The picture below shows the setup. 

Digital 
Single 
Market 

 
 
 
Figure 0-3: DG Connect demonstration setup 

The 27th of November was politically focussed with C-level representatives of the European 
Commisison, European Associations, Standardisation Development Organisations and Members of 
Parliament.  There were discussions on standards for data models and ontologies, how SDO’s should 
work together towards common standards. CEN/CENELEC clearly stated that they are committed to 
work together on ontologies such as SAREF and that the time needed to create a European standard 
ontology doesn’t need to be long.  There were questions about the introduction and price of Smart 
Appliances, and the industry representatives responded that the smartness would be “state of the 
art” within a few years. The European Commission is discussing the possibility of a label that could be 
used to indicate the “smartness” of appliances. 

Th 28th and 29th  were more technology focussed and discussed the details of standards and further 
steps to be taken. It was explained that this project will result in recommendations for the 
Coordination Groups of CEN, CENELEC and ETSI, to take the work on alignment of standards on board 
and continue with this work. 

C2. Technical description of the demonstrations 

This section desribes the technical implementation of most of the data standards that were selected 
in chapter 3. As described above, the Sierra Gateway implements the oneM2M communication layer 
and the SPINE communication layer to connect to the IoT platforms on one side and the CEM on the 
other side. SAREF4ENER is used as a common language to translate data from SPINE to COSEM and 
oneM2M resources. The diagram below shows this linking of data models 

Digital 
Single 
Market 

 
 
 
 
Smart appliances can have their own solution for a communication protocol such as HTTP, CoAP and 
SHIP (see documentation on www.eebus.org : 
https://www.eebus.org/technologie/kommunikationswege/). On the Smart Home side the data 
resources used are SPINE. On the WAN side the data is representated by oneM2M resources. The 
overarching ontology however is SAREF4ENER. 

Below you find the details of data and data transactions. 

Data Elements Definition 

Data Element 

Protocol 

Format 

Payload 

MeterDataRequest.1 

IP/Kamstrup 

Kamstrup 

getData 

MeterDataRequest.2 

HTTP/Kamstrup  OBIS 

getOBIScode 

MeterDataRequest.3 

RS485 

OBIS 

MeterReadings.1 

IP/Kamstrup 

Kamstrup 

Various consump. data, incl. A+/A-/R+/R- 

MeterReadings.2 

HTTP/Kamstrup  OBIS 

MeterReadings.3 

RS485 

OBIS 

Depends on OBIS code in request 

MeterReadingsPush.1  oneM2M/HTTP 

JSON 

MeterReadingsPush.2  ZigBee/SEP 

Fixed set of consumption data for display 

MeterReadingsResp.1  oneM2M/HTTP 

JSON 

MeterReadingsResp.2  ZigBee/SEP 

MeterCmdRequest.1 

HTTP/Kamstrup  OBIS 

Digital 
Single 
Market 

 
 
 
 
 
 
 
 
 
 
 
MeterCmdRequest.2 

IP/Kamstrup 

Kamstrup 

MeterCmdReply.1 

HTTP/Kamstrup 

MeterCmdReply.2 

IP/Kamstrup 

Kamstrup 

SAStatusRequest.1 

oneM2M/HTTP 

JSON 

SAStatusRequest.2 

HTTP/SPINE 

SAConsumRequest.1 

oneM2M/HTTP 

JSON 

SAConsumRequest.2 

HTTP/SPINE 

SAControlRequest.1a 

oneM2M/HTTP 

JSON 

Decrease Consumption command 

SAControlRequest.1b 

oneM2M/HTTP 

JSON 

Increase Consumption command 

SAControlRequest.2a  HTTP/SPINE 

Decrease Consumption command 

SAControlRequest.2b  HTTP/SPINE 

Increase Consumption command 

SAConsumData.1 

oneM2M/HTTP 

JSON 

SAConsumData.2 

HTTP/SPINE 

SAStatusData.1 

oneM2M/HTTP 

JSON 

SAStatusData.2 

HTTP/SPINE 

SAControlResponse.1  oneM2M/HTTP 

JSON 

OK or not OK 

SAControlResponse.2  HTTP/SPINE 

OK or not OK 

Use Cases 

Cluster 1: Reading and Presenting Meter Data 

UC name 

Interface 

Systems involved 

UC trigger 

UC steps 

Displaying current consumption 1 

H1 

IHD 

SM 

Smart Meter internal clock 

Step 

Sender 

Receiver 

Data Element(s) 

Digital 
Single 
Market 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1 

2 

SM 

IHD 

UC name 

Interface 

Systems involved 

UC trigger 

UC steps 

IHD 

MeterReadingsPush.2 

“Consumer” 

Reading Meter Data 3 (over H2) 

H2 

EMG 

SM 

EMG internal clock 

Step 

Sender 

Receiver 

Data Element(s) 

1 

2 

EMG 

SM 

SM 

EMG 

MeterDataRequest.3 

MeterReadings.3 

UC name 

Interface 

Reading Meter Data 4 (current) 

G3 

Systems involved 

IoTP1 / IoTP2 

EMG 

UC trigger 

UC steps 

EMG internal clock 

Step 

Sender 

Receiver 

Data Element(s) 

1 

2 

EMG 

IoTP1 + IoTP2 

MeterReadingsPush.1 

IoTP1/2 

EMG 

MeterReadingsResp.1 

MeterReadingsPush.1 Request (HTTP): 
The parts in red are susceptible to depend on the intent/situation 

POST /~/IoTPX/ESMIGDemo/SWIR-21/meter-978/1_1_1_7_0_255?rcn=0 HTTP/1.1 
Host: 52.28.68.95 
X-M2M-Origin: //52.28.68.95/SWIR-21/Meter-978 
X-M2M-RI: 123456789a 
Content-Type: application/vnd.onem2m-res+json;ty=4 

{ 
 "m2m:cin": { 
  "cnf": "application/json:0", 

Digital 
Single 
Market 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
  "con": "{\"timestamp\": 1478177480, \"value\": 1045}" 
 } 
} 

MeterReadingsResp.1Response (HTTP): 
The parts in red are susceptible to depend on the intent/situation 

HTTP/1.1 201 Created 
X-M2M-RSC: 2001 
X-M2M-RI: 123456789a 
Content-Location: /IoTPX/ESMIGDemo/cin-abcdef 

Note : careful, the format of the oneM2M exchange has changed, it used to be the following in 2016: 

Request (HTTP) – the parts in red are susceptible to depend on the intent/situation: 

POST /IoTPX/ESMIGDemo/SWIR-21/meter-978/1_1_1_7_0_255?ty=contentInstance HTTP/1.1 
Host: 52.28.68.95 
X-M2M-Origin: //52.28.68.95/SWIR-21/Meter-278 
X-M2M-RI: 123456789a 
Content-Type: application/vnd.onem2m-res+json;charset=UTF-8 

{ 
 "cnf": "application/json:0", 
 "con": "{\"timestamp\": 1478177480, \"value\": 1045}" 
} 

Response (HTTP) – the parts in red are susceptible to depend on the intent/situation: 

HTTP/1.1 200 OK 
Content-Type: application/vnd.onem2m-res+json 
Content-Length: 199 
X-M2M-RI: 123456789a 
< 
{"ri":"1478177521ri","rn":"proxy","ct":"20161103T125201","et":"20161103T125201","lt
":"20161103T125201","st":0,"cs":40,"cnf":"application\/js 
on:0","con":"{\"timestamp\": 1478177480, \"value\": 1045}"}* Connection #0 to host 
52.28.68.95 left intact 

Note: removed the use case reading current meter data real-time from IoTP to HES to SM and back. 

Cluster 2: Reading and presenting status of Smart Appliance(s) 

UC name 

Interface 

Systems involved 

Reading status of  Smart Appliance (actual) 

G3 

IoTP1 

EMG 

CEM 

UC trigger 

Manual Request in IoTP1 User Inferface 

Digital 
Single 
Market 

 
 
 
 
 
 
 
UC steps 

Step 

Sender 

Receiver 

Data Element(s) 

1 

2 

3 

4 

IoTP1 

EMG 

CEM 

EMG 

UC name 

Interface 

Systems involved 

UC trigger 

UC steps 

EMG 

CEM 

EMG 

IoTP1 

SAStatusRequest.1 

SAStatusRequest.2 

SAStatusData.2 

SAStatusData.1 

Reading consumption from Smart Appliance (actual) 

G3 

IoTP1 

EMG 

CEM 

Manual Request in IoTP1 User Inferface 

Step 

Sender 

Receiver 

Data Element(s) 

1 

2 

3 

4 

IoTP1 

EMG 

CEM 

EMG 

EMG 

CEM 

EMG 

IoTP1 

SAConsumRequest.1 

SAConsumRequest.2 

SAConsumData.2 

SAConsumData.1 

Cluster 3: Controlling Smart Meter and Appliance(s) 

UC name 

Interfaces 

Controlling Smart Meter 

G1 

Systems involved 

IoTP2 

HES 

SM 

UC trigger 

Manual Request in IoTP2 User Inferface 

UC steps 

Step 

Sender 

Receiver 

Data Element(s) 

1 

IoTP2 

HES 

MeterCmdRequest.1 

Digital 
Single 
Market 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
2 

3 

4 

HES 

SM 

HES 

SM 

HES 

IoTP2 

MeterCmdRequest.2 

MeterCmdReply.2 

MeterCmdReply.1 

UC name 

Increasing / Decreasing EEBUS Appliances Consumption 

Interfaces 

G3 

Systems involved 

IoTP1 

EMG 

CEM 

UC trigger 

Manual Request in IoTP1 User Inferface 

UC steps 

Step 

Sender 

Receiver 

Data Element(s) 

1 

2 

3 

4 

5 

6 

IoTP1 

EMG 

CEM 

SA 

CEM 

EMG 

EMG 

CEM 

SA 

CEM 

EMG 

M2M 

SAControlRequest.1a/b 

SAControlRequest.2a/b 

SAControlResponse.2 

SAControlResponse.1 

SAControlRequest.2a Request (HTTP): 
The parts in red are susceptible to depend on the intent/situation 

POST / HTTP/1.1 
Host: 192.168.1.78 
Content-Type: text/xml 

<datagram> 
  <header> 
    Specificationversion 
    AddressSource 
      Device 
      Entity 
      Feature 
    Destination 
      Device 
      Entity 
      Feature 
    MsgCounter 
    CmdClassifier 
  </header> 

Digital 
Single 
Market 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
  <payload> 
    <cmd> 
      <Function> 
    </cmd> 
  </payload> 
</datagram> 

UC name 

Inform CEM about tariff 

Interfaces 

G3 

Systems involved 

M2M platform 

EMG 

CEM 

UC trigger 

Manual request on M2M platform 

UC steps 

Sender 

Receiver 

Data Element(s) 

M2M 

EMG 

CEM 

EMG 

EMG 

CEM 

EMG 

M2M 

Example of SAREF instantiation in the demo 

# baseURI: http://www.esmig.eu/resources/saref/examples/euw17demo 
# imports: https://w3id.org/saref4ener 
@prefix euw2017-demo: <http:// www.esmig.eu/resources/saref/examples/euw17demo#> . 
@prefix owl: <http://www.w3.org/2002/07/owl#> . 
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . 
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . 
@prefix saref: <https://w3id.org/saref#> . 
@prefix time: <http://www.w3.org/2006/time#> . 
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> . 
@prefix euw17demo: <http://www.esmig.eu/resources/saref/examples/euw17demo#> . 

<http://www.esmig.eu/resources/saref/examples/euw17demo> 
  rdf:type owl:Ontology ; 
  owl:imports <https://w3id.org/saref4ener> ; 
. 

euw17demo:SmartMeter 
  rdf:type s4ener:Device ; 
  rdfs:label "Smart Meeter"^^xsd:string ; 
  saref:hasDescription "Kamstrup Smart Power Meter"^^xsd:string ; 
. 

euw17demo:Energy_1 
  rdf:type s4ener:Energy ; 
  rdfs:label "Energy 1"^^xsd:string ; 

Digital 
Single 
Market 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
  saref:relatesToMeasurement s4ener:Measurement_1 ; 
  saref:isMeasuredByDevice s4ener:SmartMeter; 
. 

euw17demo:Power_1 
  rdf:type s4ener:Power ; 
  rdfs:label "Power 1"^^xsd:string ; 
  saref:isMeasuredByDevice s4ener: SmartMeter; 
  saref:relatesToMeasurement s4ener:Measurement_2 ; 
. 

euw17demo:Measurement_1 
  rdf:type saref:Measurement ; 
  rdfs:label "Measurement 1"^^xsd:string ; 
  saref:hasValue "0.2"^^xsd:string ; 
  saref:isMeasuredIn <http://www.wurvoc.org/vocabularies/om-1.8/kilowatt_hour> ; 
  saref:relatesToProperty s4ener:Energy_1 ; 
. 

euw17demo:Measurement_2 
  rdf:type saref:Measurement ; 
  rdfs:label "Measurement 2"^^xsd:string ; 
  saref:hasValue "0.2"^^xsd:string ; 
  saref:isMeasuredIn <http://www.wurvoc.org/vocabularies/om-1.8/kilowatt> ; 
  saref:relatesToProperty s4ener:Power_1 ; 
. 

Digital 
Single 
Market 

 
 
 
 
 
 
 
 
 
 
 
European Commission 

Study on ensuring interoperability for enabling Demand Side 
Flexibility 
Luxembourg, Publications Office of the European Union 

2018 – 140 pages  

ISBN 978-92-79-91236-8 
doi: 10.2759/26799 

Digital 
Single 
Market 

 
 
 
 
 
 
 
 
K
K
-
0
3
-
1
8
-
1
2
1
-
E
N
N

-

doi: 10.2759/26799 

ISBN 978-92-79-91236-8 

Electronically signed on 14/11/2018 13:45 (UTC+01) in accordance with article 4.2 (Validity of electronic documents) of Commission Decision 2004/563