EN 50631-3-1:2023

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: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.

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 l'EN 50631-1:2023 avec des langages spécifiques; en l'occurrence, les langages SPINE et SPINE-IoT. 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

• Status: Published
• Publication Date: 16-Mar-2023
• ICS: 97.120 - Automatic controls for household use
• Technical Committee: CLC/TC 59X - Consumer information related to household electrical appliances
• Drafting Committee: CLC/TC 59X - Consumer information related to household electrical appliances
• Current Stage: 6060 - Document made available - Publishing
• Start Date: 17-Mar-2023
• Due Date: 09-Dec-2022
• Completion Date: 17-Mar-2023
• Ref Project: SIST EN 50631-3-1:2023 - Household appliances network and grid connectivity - Part 3-1: Specific Data Model Mapping: SPINE and SPINE-IoT

Overview

EN 50631-3-1:2023 (CLC) - Household appliances network and grid connectivity - Part 3-1 - defines how the generic use case functions and neutral data models from EN 50631-1:2023 are mapped to concrete data model languages: SPINE and SPINE‑IoT. Approved by CENELEC in 2023, this part of the EN 50631 series focuses on data model mapping to enable interoperable information exchange between smart appliances and Home/Building or Customer Energy Management Systems (CEM/EMS). The document targets appliance-to-management-system communication for energy management, remote control and monitoring; it does not define safety or security requirements.

Key Topics

• Mapping of Generic Use Case Functions (UCFs): Detailed mappings from the neutral model to SPINE and SPINE‑IoT for many UCFs (examples in the standard include Measurement, Device_Configuration, Plan_With_Power_Sequences, Power_Limit, Heartbeat, and more).
• SPINE concepts and hierarchy: Definitions for device, entity, feature, function, element and namespace to ensure consistent SPINE addressing and payload structure.
• SPINE‑IoT specifics: Includes YAML models and concise mappings tailored for constrained or IoT-focused environments.
• Reader guidance: Diagrams and guidance on interpreting hierarchy and sequence diagrams and locating relevant mapping information.
• Interoperability focus: Emphasis on neutral messages and separating data modelling from transport/protocol specifics so that multiple communication technologies can be used without changing the information model.
• No normative references: The document contains its own terms and definitions and focuses on mapping rather than creating new normative dependencies.

Applications

Who benefits and how:

• Appliance manufacturers - implement SPINE or SPINE‑IoT endpoints to expose device functions in a way that interoperates with third‑party energy management systems.
• Software developers & integrators - build CEM/EMS platforms that understand mapped UCFs (measurement, power sequences, device configuration) to orchestrate appliance behavior and demand response.
• System architects & IoT solution providers - design gateways or cloud services that translate between neutral messages and SPINE(SPINE‑IoT) payloads.
• Test labs and certification bodies - verify conformance of device implementations to the mapping rules to ensure cross‑vendor interoperability.
• Utilities & energy managers - enable flexible demand‑side management and grid‑aware appliance control by relying on standardized data models.

Related Standards

• EN 50631-1:2023 - General requirements, generic data modelling and neutral messages (source of the UCFs)
• EN 50631-2, -4, -5, -6 - Product mappings, protocol aspects, testing, and SPINE toolbox (parts of the wider EN 50631 series)

Keywords: EN 50631-3-1, SPINE, SPINE‑IoT, household appliances network, grid connectivity, data model mapping, smart appliances, energy management, interoperability, neutral message, use case functions.

Standards Content (Sample)

SLOVENSKI STANDARD
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
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

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
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
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.
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.
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
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

SPINE address part for the (physical) 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
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
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,
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)
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.
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.
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).
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 with the same major version number as supported by Actor A, the Actor A SHOULD evaluate
from these versions of Actor B only the highest version number.
— If an Actor A supports multiple versions of this Use Case with different major version numbers, for each
major version number only the highest version number SHOULD be set within the Use Case discovery.
— If an Actor A finds a proper counterpart Actor B for this Use Case that supports only versions with a major
version number not implemented by Actor A, it still might be possible to run the Use Case or parts of the
Use Case. Therefore, the Actor A should try to evaluate the Actor B as a valid partner for this Use Case.
5.2.1.1.2.2 Limitation of Power Consumption
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 “limitationOfPowerConsumption”. 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 with the same major version number as supported by Actor A, the Actor A SHOULD evaluate
from these versions of Actor B only the highest version number.
— If an Actor A supports multiple versions of this Use Case with different major version numbers, for each
major version number only the highest version number SHOULD be set within the Use Case discovery.
— If an Actor A finds a proper counterpart Actor B for this Use Case that supports only versions with a major
version number not implemented by Actor A, it still might be possible to run the Use Case or parts of the
Use Case. Therefore, the Actor A should try to evaluate the Actor B as a valid partner for this Use Case.
5.2.1.1.2.3 Monitoring and Control of Smart Grid Ready Conditions
Use Case discovery SHOULD be supported by each Actor. If Use Case discovery is supported, 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 “monitoringAndControlOfSmartGridReadyConditions”. 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 with the same major version number as supported by Actor A, the Actor A SHOULD evaluate
from these versions of Actor B only the highest version number.
— If an Actor A supports multiple versions of this Use Case with different major version numbers, for each
major version number only the highest version number SHOULD be set within the Use Case discovery.
— If an Actor A finds a proper counterpart Actor B for this Use Case that supports only versions with a major
version number not implemented by Actor A, it still might be possible to run the Use Case or parts of the
Use Case. Therefore, the Actor A should try to evaluate the Actor B as a valid partner for this Use Case.
5.2.1.1.2.4 Monitoring of Power Consumption
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 SPINE Protocol Specification
EN 50631-4-1) SHALL be “monitoringOfPowerConsumption”. 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 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 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 with the same major version number as supported by Actor A, the Actor A SHOULD evaluate
from these versions of Actor B only the highest version number.
— If an Actor A supports multiple versions of this Use Case with different major version numbers, for each
major version number only the highest version number SHOULD be set within the Use Case discovery.
— If an Actor A finds a proper counterpart Actor B for this Use Case that supports only versions with a major
version number not implemented by Actor A, it still might be possible to run the Use Case or parts of the
Use Case. Therefore, the Actor A should try to evaluate the Actor B as a valid partner for this Use Case.
5.2.1.1.2.5 Optimization of Self Consumption by Heat Pump Compressor Flexibility
Use Case discovery SHOULD be supported by each Actor. If Use Case discovery is supported, 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
“optimizationOfSelfConsumptionByHeatPumpCompressorFlexibility”. 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 with the same major version number as supported by Actor A, the Actor A SHOULD evaluate
from these versions of Actor B only the highest version number.
— If an Actor A supports multiple versions of this Use Case with different major version numbers, for each
major version number only the highest version number SHOULD be set within the Use Case discovery.
— If an Actor A finds a proper counterpart Actor B for this Use Case that supports only versions with a major
version number not implemented by Actor A, it still might be possible to run the Use Case or parts of the
Use Case. Therefore, the Actor A should try to evaluate the Actor B as a valid partner for this Use Case.
5.2.1.1.3 Rules for “Information content” tables
5.2.1.1.3.1 General presence indication definitions
Abbreviations for the presence indication of Elements listed in the tables are defined as follows (see Table 1):
Table 1 — Presence indication description
Abbreviation Meaning Link to requirement keywords
M Mandatory SHALL
R Recommended SHOULD
O Optional MAY
F Forbidden SHALL NOT
An Actor MAY support Elements that are not listed in the tables. However, another Actor MAY ignore these
Elements.
The presence indications “M”, “R” and “O” are always meant relative to the respective parent Element. I.e. if a
parent Element is optional (“O”) and a child is mandatory (“M”) the child Element can only be present if the
parent Element is present as well.
NOTE The indications and the aforementioned rules apply for “complete messages” (so-called “full function
exchange”; refer to SPINE Protocol Specification EN 50631-4-1). In contrast, the so-called “restricted function exchange”
is designed to permit exchange of specific excerpts of data, i.e. fewer Elements than potentially available from the data
owner (partially even not all “mandatory” Elements).
In some cases, an Element may have a double presence indication, separated by a colon.
Examples:
M, O
M \W, O \W
The description (rules) of the Element details in such a case the presence requirement. A typical example is a
list-based Element where the “first” (or “last”) Element has a different presence requirement than the other list
Elements.
5.2.1.1.3.2 Cardinality indications on Elements and list items
A cardinality indication on an Element or list item expresses constraints on the number of occurrences of a
given Element or data set. In this subclause we use “X” as representation for such an Element or data set.
Furthermore, “a” and “b” represent constraints. The following rules apply for the occurrence of “X” and its
content related to a specific Scenario (see note underneath the list):
1. X
No cardinality indication.
2. X (a.b)
This means “X” SHALL occur at least “a” times and at maximum “b” times.
3. X (a.)
This means “X” SHALL occur at least “a” times and MAY occur more than “a” times.
4. X (.b)
This means “X” SHALL occur at maximum “b” times and MAY occur less than “b” times (even zero
occurrences are permissive).
NOTE These rules apply only under consideration of presence indications and with regard to the given Scenario or
Function definition for this Use Case.
Table 2 is an example to explain this for two different placements.
Table 2 — Example table for cardinality indications on Elements and list items
... ...  ...
2: M \W xFeatureType. xListData. xData. (1.3)
2: M \W xId < *#(1.) > PRIMARY IDENTIFIER
2: M \W timePeriod  .
2: M \W timePeriod. startTime
2: M \W xSlot. (1.)
2: M \W xSlot. xSlotId  .
2: M \W xSlot. duration .
... ... ... ...
The field
xFeatureType. xListData. xData. (1.3)
introduces a data pattern (required Elements and values) for “xData” instances used for Scenario 2. The field
itself specifies that such an “xData” instance SHALL occur at least 1 time and at maximum 3 times within
“xListData” of Feature Type “xFeatureType”. However, this constraint holds only for Scenario 2 and only if
such “xData” are required. In this case, they are required, as the left field
2: M \W
denotes that this data set is mandatory for Scenario 2.
The field
xSlot. (1.)
expresses that the Element “xSlot” SHALL occur at least one time within its “xData”, but MAY occur more than
one time.
For the expression “<*#(1.)>” of Element “xId”, see 5.2.1.1.3.4.
The remaining fields do not have an explicit cardinality indication.
NOTE Cardinality expressions are also used within placeholder expressions as defined in 5.2.1.1.3.4. In many cases
such placeholder expressions define the number of required or permitted Elements or list items as they explicitly define
how many different values for a given Identifier are required or permitted for a given Scenario.
5.2.1.1.3.3 Writability and changeability indication
In the same column where the presence indications are denoted, a mark is used to distinguish between
writeable, changeable or readable Elements:
— Elements that are marked with “\W” are written by a client and SHALL be writeable at the server
according to their presence indications. The client is not obliged to read the according data. Received
notifications do not need to be evaluated.
Scenario [{.}]:
M/R/O [\W][\C]
Element
Value
Element and value
rules
— Elements that are marked with “\C” are changed by a client and SHALL be changeable at the server
according to their presence indications. The client is not obliged to read the according data. Received
notifications do not need to be evaluated.
— Elements that are marked with “\RW” are read and written by a client and SHALL be writeable and
provided by the server according to their presence indications. Received notifications SHALL be
evaluated according to their presence indications.
— Elements that are marked with “\RC” are read and changed by a client and SHALL be changeable and
provided by the server according to their presence indications. Received notifications SHALL be
evaluated according to their presence indications.
— Elements that are not marked are only read by a client and SHALL be provided by the server according to
their presence indications. Received notifications SHALL be evaluated according to their presence
indications.
“Writeable” means that the Element and its value may be written by a client. T
...