SIST EN 50631-3-1:2023
(Main)Household appliances network and grid connectivity - Part 3-1: Specific Data Model Mapping: SPINE and SPINE-IoT
Household appliances network and grid connectivity - Part 3-1: Specific Data Model Mapping: SPINE and SPINE-IoT
This document maps the generic use case functions and data models defined in EN 50631-1:202X to specific languages; in this case, SPINE.
This document is part of EN 50631 series which defines the information exchange between Smart Appliances and management systems in homes and buildings including energy management.
Netzwerk- und Stromnetz-Konnektivität von Haushaltsgeräten - Teil 3-1: Mapping auf spezifische Datenmodelle: SPINE und SPINE-IoT
Appareils domestiques connectés au réseau et réseau intelligent - Partie 3-1: Mapping avec des modèles de données spécifiques: SPINE et SPINE-IoT
Le présent document établit un mapping des fonctions et des modèles de données de cas d'utilisation génériques définis dans le prEN 50631 1:2021 avec des langages spécifiques; en l'occurrence, le langage SPINE.
Le présent document fait partie de la série EN 50631 qui définit l'échange d'informations entre les appareils intelligents et les systèmes de gestion des habitations et des bâtiments, y compris pour la gestion d'énergie.
Omrežje gospodinjskih aparatov in povezljivost mreže - 3-1. del: Mapiranje posebnih podatkovnih modelov: SPINE in SPINE-IoT
Ta dokument vključuje pregled funkcij splošnih primerov uporabe in podatkovnih modelov, določenih v standardu EN 50631-1:202X za določene jezike; v tem primeru, SPINE.
Ta dokument je del skupine standardov EN 50631, ki določa izmenjavo informacij med pametnimi gospodinjskimi aparati in sistemi za upravljanje v gospodinjstvih in stavbah, vključno z upravljanjem z energijo.
General Information
Standards Content (Sample)
SLOVENSKI STANDARD
SIST EN 50631-3-1:2023
01-maj-2023
Omrežje gospodinjskih aparatov in povezljivost mreže - 3-1. del: Mapiranje
posebnih podatkovnih modelov: SPINE in SPINE-IoT
Household appliances network and grid connectivity - Part 3-1: Specific Data Model
Mapping: SPINE and SPINE-IoT
Netzwerk- und Stromnetz-Konnektivität von Haushaltsgeräten - Teil 3-1: Mapping auf
spezifische Datenmodelle: SPINE und SPINE-IoT
Appareils domestiques connectés au réseau et réseau intelligent - Partie 3-1: Mapping
avec des modèles de données spécifiques: SPINE et SPINE-IoT
Ta slovenski standard je istoveten z: EN 50631-3-1:2023
ICS:
97.120 Avtomatske krmilne naprave Automatic controls for
za dom household use
SIST EN 50631-3-1:2023 en
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
---------------------- Page: 1 ----------------------
SIST EN 50631-3-1:2023
---------------------- Page: 2 ----------------------
SIST EN 50631-3-1:2023
EUROPEAN STANDARD EN 50631-3-1
NORME EUROPÉENNE
EUROPÄISCHE NORM March 2023
ICS 97.120
English Version
Household appliances network and grid connectivity - Part 3-1:
Specific Data Model Mapping: SPINE and SPINE-IoT
Appareils domestiques connectés au réseau et réseau Netzwerk- und Stromnetz-Konnektivität von
intelligent - Partie 3-1: Mapping avec des modèles de Haushaltsgeräten - Teil 3-1: Mapping auf spezifische
données spécifiques: SPINE et SPINE-IoT Datenmodelle: SPINE und SPINE-IoT
This European Standard was approved by CENELEC on 2023-02-13. CENELEC members are bound to comply with the CEN/CENELEC
Internal Regulations which stipulate the conditions for giving this European Standard the status of a national standard without any alteration.
Up-to-date lists and bibliographical references concerning such national standards may be obtained on application to the CEN-CENELEC
Management Centre or to any CENELEC member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by translation
under the responsibility of a CENELEC member into its own language and notified to the CEN-CENELEC Management Centre has the
same status as the official versions.
CENELEC members are the national electrotechnical committees of Austria, Belgium, Bulgaria, Croatia, Cyprus, the Czech Republic,
Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, the
Netherlands, Norway, Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland,
Türkiye and the United Kingdom.
European Committee for Electrotechnical Standardization
Comité Européen de Normalisation Electrotechnique
Europäisches Komitee für Elektrotechnische Normung
CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2023 CENELEC All rights of exploitation in any form and by any means reserved worldwide for CENELEC Members.
Ref. No. EN 50631-3-1:2023 E
---------------------- Page: 3 ----------------------
SIST EN 50631-3-1:2023
EN 50631-3-1:2023 (E)
Contents Page
European foreword . 3
Introduction . 3
1 Scope . 5
2 Normative references . 5
3 Terms and definitions . 5
4 Reader’s guide . 10
4.1 Reading the graphics . 10
4.1.1 General . 10
4.1.2 Hierarchy diagram . 10
4.1.3 Sequence diagram . 11
4.2 Finding the right information. 12
5 Use Case Function (UCF) details . 12
5.1 General . 12
5.2 Mapping to SPINE . 12
5.2.1 Concepts. 12
5.2.2 UCF_AC_Measurement . 27
5.2.3 UCF_Characteristics . 50
5.2.4 UCF_Configure_Current_Power_Sequence . 55
5.2.5 UCF_Consumption_Curve . 57
5.2.6 UCF_Device_Configuration . 69
5.2.7 UCF_Device_Connected . 81
5.2.8 UCF_Heartbeat . 82
5.2.9 UCF_Incentive_Table . 86
5.2.10 UCF_Overrun . 117
5.2.11 UCF_Plan_With_Power_Sequences . 124
5.2.12 UCF_Power_Limit . 133
5.2.13 UCF_Report_Status_Of_Power_Sequence . 139
5.2.14 UCF_Select_Power_Sequence . 145
5.2.15 UCF_Shift_Preferred_Power_Sequence . 147
5.2.16 UCF_System_Function . 150
5.3 Mapping to SPINE-IoT . 155
5.3.1 Concepts. 155
5.3.2 UCF_Configure_Current_Power_Sequence . 157
5.3.3 UCF_Device_Connected . 159
5.3.4 UCF_Plan_With_Power_Sequences . 159
5.3.5 UCF_Select_Power_Sequence . 165
5.3.6 UCF_Shift_Preferred_Power_Sequence . 165
5.3.7 YAML models for SPINE-IoT . 167
Bibliography . 199
2
---------------------- Page: 4 ----------------------
SIST EN 50631-3-1:2023
EN 50631-3-1:2023 (E)
European foreword
This document (EN 50631-3-1:2023) has been prepared by WG 07 “Smart Household Appliances” of CLC/TC
59X “Performance of household and similar electrical appliances”.
The following dates are fixed:
• latest date by which this document has to be (dop) 2024-02-13
implemented at national level by publication of
an identical national standard or by
endorsement
• latest date by which the national standards (dow) 2026-02-13
conflicting with this document have to be
withdrawn
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. CENELEC shall not be held responsible for identifying any or all such patent rights.
Any feedback and questions on this document should be directed to the users’ national committee. A
complete listing of these bodies can be found on the CENELEC website.
3
---------------------- Page: 5 ----------------------
SIST EN 50631-3-1:2023
EN 50631-3-1:2023 (E)
Introduction
Energy management systems will more and more become necessary due to change from fossil and nuclear to
renewable production and the associated decentralization. Since an appropriate standard for a home and
building management is in preparation this document specifies how sets of products from multiple
manufacturers can exchange information with Home and Building / Customer Energy Management Systems,
located in a home network or in the cloud.
This document focuses on interoperability of household appliances and describes the necessary control and
monitoring. It defines a set of functions of household and similar electrical appliances. The functions in this
document cover next to energy-management main remote-control and – monitoring use cases.
This document does not deal with safety and security requirements. Safety requirements have been set in the
EN 60335 series [1]. EN 50631 will provide interoperability on information exchange among various
appliances in the home. The EN 50631 document series will be re-arranged regarding the further
development and will be split into 6 parts:
— EN 50631-1, Household appliances network and grid connectivity — Part 1: General Requirements,
Generic Data Modelling and Neutral Messages
— EN 50631-2, Household appliances network and grid connectivity — Part 2: Product Specific mappings,
details, requirements and deviations
— EN 50631-3-x, Household appliances network and grid connectivity — Part 3: Specific Data Model
Mapping
— EN 50631-4-x, Household appliances network and grid connectivity — Part 4: Communication Protocol
Specific Aspects
— EN 50631-5, Household appliances network and grid connectivity — Part 5: General Test-Requirements
and - Specification
— EN 50631-6, Household appliances network and grid connectivity — Part 6: SPINE Data Model Toolbox
Data communication heavily depends on the environment of appliances. Sometimes low bitrate or energy
efficient communication puts strict requirements to selected communication technologies. Therefore, popular
and de facto standards had been and will be developed by the industry to fulfil such requirements. To not
influence common data modelling for appliances because of such restrictions, the standardized data models
and neutral message structures need to be applied to communication technologies.
This standard series therefore is intended to separate data modelling and neutral message structure from the
attached communication.
Part 1 defines general requirements, generic data modelling and generic neutral messages without relation to
any specific communication technology or any product specific layout.
Part 2 lists and specifies product specific requirements and implementation guidance based on the generic
data model and generic neutral messages.
Part 3 defines the mapping of neutral messages to examples of typical data models like SPINE, SPINE-IoT,
OCF, and so forth. These data models are neither mandatory nor to be seen as complete spectrum of data
models.
Part 4 defines the mapping of neutral messages to examples of typical communication protocols. These
communication protocols are neither mandatory, nor do they provide an exhaustive list of communication
protocols.
Part 5 defines testing requirements and testing specifications. This part will be covered in the future by a New
Work Item Proposal.
Part 6 provides the technical reference specification for the SPINE data model. This part will be covered in the
future by a New Work Item Proposal.
4
---------------------- Page: 6 ----------------------
SIST EN 50631-3-1:2023
EN 50631-3-1:2023 (E)
1 Scope
This document maps the generic use case functions and data models defined in EN 50631-1:2023 to specific
languages; in this case, SPINE and SPINE-IoT.
This document is part of the EN 50631 series, which defines the information exchange between Smart
Appliances and management systems in homes and buildings including energy management.
2 Normative references
There are no normative references in this document.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https://www.iso.org/obp
— IEC Electropedia: available at https://www.electropedia.org/
3.1
appliance
electrical apparatus intended for household or similar use
EXAMPLES Refrigerators, dishwashers, clothes washers, clothes dryers, air conditioners, water heaters, circulation
pumps, heat pumps, etc.
3.2
Appliance Energy Flexibility
ability of an appliance to change power consumption in response to an external stimulus
3.3
binding
concept for connecting functionally matching features
3.4
classifier
role that specifies whether a message serves to read, reply, write, etc
3.5
client
role that specifies that a node uses data from a “server” or can request for change
3.6
command
functional part of a Message
3.7
CCM
Customer Connectivity Manager
component or set of functions with the capability to:
1. Receive and process Grid Information, Appliance Information and User Instructions, and
2. Manage one or more Smart Appliances
5
---------------------- Page: 7 ----------------------
SIST EN 50631-3-1:2023
EN 50631-3-1:2023 (E)
Note 1 to entry: A CCM may be integrated with a Smart Appliance or may be physically separate.
Note 2 to entry: A CCM manages the energy-using behaviour as well as other aspects of device behaviour (e.g. setting
of job status like starting, stopping, pausing, parameters like temperature, notifications.) of one or more Smart
Appliances.
Note 3 to entry: In other documentation, CCM is often called Customer Energy Manager (CEM) with a dedicated focus
on energy management or called Energy Management System (EMS) with a dedicated focus on energy management.
3.8
data model
definition of possible data (data structures, values) for the exchange of information (especially for
communications systems)
[SOURCE: IEC 60050, IEV] [2]
3.9
Demand Response
DR
action resulting from management of the electricity demand in response to supply conditions
[SOURCE: IEC 60050, IEV] [2]
3.10
Demand Side Management
DSM
process that is intended to influence the quantity or patterns of use of electric energy consumed by end-use
customers
3.11
device
SPINE node that can include a set of entities
Note 1 to entry: It has a “deviceType”. With regard to the hierarchy of SPINE nodes a device is a root node for all
functionalities offered by a device.
3.12
device
Note 1 to entry: The address part shall be written between quotation marks, e.g., “device”.
3.13
deviceType
specific type of physical device (e.g., “WashingMachine”, “HeatPump”, “FridgeFreezer”, etc.)
3.14
discovery
process of finding appropriate partners for communication.
Note 1 to entry: Dependent on the context this can be either finding other devices or examination of a device’s potential
functionalities.
3.15
element
item (or “attribute”) of a SPINE function which holds one information (e.g. “timestamp”, “value”, etc.) or
contains further sub-elements
6
---------------------- Page: 8 ----------------------
SIST EN 50631-3-1:2023
EN 50631-3-1:2023 (E)
3.16
entity
SPINE node that can include a set of (sub-)entities or features
Note 1 to entry: It has an “entityType”. With regard to the hierarchy of SPINE nodes an entity is a sub-element of a
device.
3.17
entity
SPINE address part for the (logical) entity
Note 1 to entry: The address part shall be written between quotation marks, e.g., “entity”.
3.18
EntityType
specific type of logical device (e.g. “Freezer” is one logical part of a physical device “FridgeFreezer”)
3.19
feature
SPINE node that can include a set of functions (of a class)
Note 1 to entry: It has a “featureType”. With regard to the hierarchy of SPINE nodes a feature is a sub-element (i.e.
“child”) of an entity.
3.20
feature
SPINE address part for one feature
Note 1 to entry: The address part shall be written between quotation marks, e.g., “feature”.
3.21
FeatureType
type that defines optional or mandatory rules and a general behaviour of the underlying Class (standard or
complex)
3.22
function
smallest structure to model “actual data” (“functional data”), i.e. functions usually consist of child elements that
each hold an information (e.g. “timestamp”, “value”, etc.)
Note 1 to entry: Information between communication partners is exchanged via the exchange of a function (as part of a
so-called “payload”).
3.23
message
one SPINE transfer from a sender to a receiver
3.24
namespace
XML namespace
set of names that provides a simple method for qualifying element and attribute names used in XML
documents by associating them with namespaces identified by URI references [3]
3.25
neutral message
information exchange that is independent of any specific communication solution
7
---------------------- Page: 9 ----------------------
SIST EN 50631-3-1:2023
EN 50631-3-1:2023 (E)
Note 1 to entry: This document describes the mapping of neutral messages to examples of typical communication
protocols.
3.26
node
common term for a SPINE instance that has a SPINE address
Note 1 to entry: Dependent on the situation a node can be either a device or an entity (of a specific device) or a feature
(of a specific device-entity).
3.27
payload
SPINE Payload, containing the functional SPINE data
3.28
power sequence
expected power consumption over time (i.e., represented as a “curve” of power over time) including options on
its flexibility
3.29
RMS
Root Mean Square of a set of numbers
3.30
role
each Feature has a functional role, usually either “server” (data owner) or “client”
Note 1 to entry: For some special features (e.g. NodeManagement) the role “special” is defined.
3.31
scope type
feature type that defines scope types for identifying specific functionalities unambiguously (e.g.,
outsideAirTemperature)
3.32
server
role that specifies that a node offers own data to be read or written by a node with role client
Note 1 to entry: A server can notify its data to other nodes (with role client).
3.33
smart appliance
appliance that is capable of Smart Operation
Note 1 to entry: Notwithstanding the possibly broader concept related to the term “smart appliance”, a smart appliance
under the framework of this document needs to be understood as follows:
1) It is an appliance that can respond to an external stimulus initiated by a CCM and/or Remote Agent to provide
activities such as
a. Support Appliance Energy Flexibility
b. job status related functions such as starting, stopping, pausing,
c. content or level related functions such as temperature, door status.
2) The appliance will respond when the user sets conditions and its status allows for a response,
8
---------------------- Page: 10 ----------------------
SIST EN 50631-3-1:2023
EN 50631-3-1:2023 (E)
3) The response is a change of the appliance’s behaviour like electricity consumption, job status and/or level or
content pattern, or a notification thereof,
4) The specific technical smart capabilities need not be activated when the product is placed on the market; the
activation can be done at a later point in time by the consumer or a service provider.
Note 2 to entry: Smart appliances in this context can communicate through a Customer Connectivity Manager function
processing external signals, such as price information or availability of Renewable Energy Sources (demand response), or
direct control signals (demand side management), being able to consider households’ preferences or the behaviour of the
other home appliances.
3.34
smart operation
operation of an Appliance where the CCM has been set to modify operation automatically in response to
Trigger Criteria
Note 1 to entry: Smart operation may be initiated by a CCM.
3.35
SPINE
Smart Premises Interoperable Neutral-message Exchange
3.36
SPINE-IoT
Smart Premises Interoperable Neutral-message Exchange for Internet of Things
3.37
SPINE Data Model
data model which describes the concepts and data model to ensure information exchange between devices
like Smart Appliance and CCM, including
1) SPINE Protocol, defining a neutral message structure and neutral message exchange
2) SPINE Feature Types, describing the specific information to be exchanged
3.38
subscription
concept that enables the receiving of messages of interest from another device without polling it
3.39
Use Case
textual description of a re-usable functionality, consisting of one or more messages from one or more
participating actors, which may be visualized with a sequence diagram, e.g. “A CCM shifts the energy usage
of a washing machine”
3.40
Use Case Functions
Functions which group basic functionalities that had been derived from use cases
Note 1 to entry: These functions provide the entire information exchange required to implement the considered use
cases and user stories.
3.41
XML
Extensible Markup Language
simple, very flexible text format derived from SGML (ISO 8879)
9
---------------------- Page: 11 ----------------------
SIST EN 50631-3-1:2023
EN 50631-3-1:2023 (E)
Note 1 to entry: See [3]. Extensible Mark-up Language (XML) defines a set of rules for encoding documents in a format
that is both human-readable and machine-readable, enabling multiple publishing options and other applications for a
variety of different purposes. Used to model SPINE messages.
3.42
XSD
XML Schema Definition
schema to define and describe a class of XML documents by using schema components to constrain and
document the meaning, usage and relationships of their constituent parts: datatypes, elements and their
content and attributes and their values, see [3]
Note 1 to entry: The SPINE data model is defined in XSD and supplementary documents (as not every rule can be
specified with XSD only). Other formats than XML can be derived from an XSD, too (e.g. JSON).
3.43
YAML
YAML Human-Readable Data-Serialization Language
schema to define and describe a class of XML documents by using schema components to constrain and
document the meaning, usage and relationships of their constituent parts: datatypes, elements and their
content and attributes and their values
Note 1 to entry: The SPINE-IoT data model is defined in YAML and supplementary documents (as not every rule can be
specified with YAML only). Other formats than YAML can be derived from an YAML, too (e.g. JSON).
4 Reader’s guide
4.1 Reading the graphics
4.1.1 General
This document contains several graphical representations based on plantUML [4], especially in Clause 6 and
later. In order to facilitate their interpretation by readers unfamiliar with UML, the following provides an
introduction.
4.1.2 Hierarchy diagram
Within the “Actor [.] overview” diagrams in the “Actors” sub-sections the complete functionality of this Use
Case is provided. The Actor MAY have more functionality implemented than needed for this Use Case.
For the following Actor overview example (see Figure 1), a brief description of the graphical symbols will be
described.
10
---------------------- Page: 12 ----------------------
SIST EN 50631-3-1:2023
EN 50631-3-1:2023 (E)
Figure 1 — Actor overview example
The solid lines in the figure represent an immediate parent-childhood relation: The Entity with “ A>” is a direct child of “Device”. The Entity with “” is a direct child of the Entity with “ Type B>”. All Features are immediate child of the respective Entity.
The dashed lines in the figure express that there MAY be additional Entities between the shown Entities: A
vendor's implementation MAY have one or more Entities between “Device” and the Entity with “ B>”. Likewise, a vendor's implementation MAY have one or more Entities between the Entity with “ Type B>” and the Entity with “”.
The entityType “DeviceInformation” with the featureType “NodeManagement” is required by the SPINE
protocol and therefore SHALL be supported. Both types are added in the figure for completeness but are not
directly linked to the Use Case.
4.1.3 Sequence diagram
Communication sequence diagrams visualize the messages sent between actors as part of a Use Case
function or scenario, as shown in this example in Figure 2:
Figure 2 — Example communication sequence diagram
The participating actors are represented by rectangles with their names at the top of the diagram (and
optionally at the bottom), as well as by a connecting vertical line.
11
---------------------- Page: 13 ----------------------
SIST EN 50631-3-1:2023
EN 50631-3-1:2023 (E)
Horizontal arrows indicate the types of messages sent as well as their direction. In the above example, the
first message is a read command of the data structure called “smartEnergyManagementPsData” initiated by
the CCM and sent to the Device; the second message is the Device’s reply. Note that time always flows from
top to bottom.
4.2 Finding the right information
The Use Case Functions are described in Clause 5. Each Use Case Function is documented in detail as a
SPINE and SPINE-IoT reference solution.
5 Use Case Function (UCF) details
5.1 General
In the following, the mapping of the Use Case functions from EN 50631-1 to SPINE and SPINE-IoT is
described.
This document defines the mapping of neutral messages to examples of typical data models like SPINE, and
SPINE-IoT. Specifically, it describes SPINE-Resources and SPINE-IoT-Resources mapped from the the high-
level Use Case Functions as shown in Figure 3.
Figure 3 — Description of EN 50631-3
5.2 Mapping to SPINE
5.2.1 Concepts
5.2.1.1 General rules and information
5.2.1.1.1 Underlying technology documents
This technical solution relies on the SPINE Protocol Specification (see EN 50631-4-1) and the SHIP
Specification as transport protocol (see EN 50631-4-1).
12
---------------------- Page: 14 ----------------------
SIST EN 50631-3-1:2023
EN 50631-3-1:2023 (E)
5.2.1.1.2 Use Case discovery rules
5.2.1.1.2.1 Incentive Table-based Power Consumption Management
Use Case discovery SHALL be supported by each Actor and the following rules SHALL apply:
— The string content for the Element “nodeManagementUseCaseData. useCaseInformation.
useCaseSupport. useCaseName” within the Use Case discovery (refer to the SPINE Protocol
Specification EN 50631-4-1) SHALL be “incentiveTableBasedPowerConsumptionManagement”. The
string content SHALL only be defined by this Use Case (regardless of the Use Case version).
— The string content of the Element “nodeManagementUseCaseData. useCaseInformation. actor” within
the Use Case discovery (refer to the SPINE Protocol Specification EN 50631-4-1) SHALL be set to the
according value stated within the corresponding Actor's section.
— An Actor A that is implemented to support this Use Case specification SHALL set the Element
“nodeManagementUseCaseData. useCaseInformation. useCaseSupport. useCaseVersion” within the
Use Case discovery (refer to the SPINE Protocol Specification EN 50631-4-1) to “1.0.0”.
— If an Actor A supports multiple versions of this Use Case with the same major version number, only the
highest one SHOULD be set within the Use Case discovery.
— If an Actor A finds a proper counterpart Actor B for this Use Case that supports multiple versions of this
Use Case
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.