EEBus UC TS MonitoringOfBattery V1.0.0 RC4 Public

EEBus Initiative e.V.
Deutz-Mülheimer-Straße 183
51063 Cologne
GERMANY
Rue d’Arlon 25
EEBus UC Technical Specification 1050 Brussels
BELGIUM
Phone: +49 221 / 715 938 - 0
Monitoring of Battery Fax: +49 221 / 715 938 - 99
info@eebus.org
www.eebus.org
Version 1.0.0 RC4
District court: Cologne
VR 17275
Cologne, 2022-12-22
The EEBus concept was

developed as part
of E-Energy.
EEBus UC TS - Monitoring of Battery V1.0.0 RC4
Terms of use for publications of EEBus Initiative e.V.
General information
The specifications, particulars, documents, publications and other information provided by the EEBus Initiative e.V. are solely for general
informational purposes. Particularly specifications that have not been submitted to national or international standardisation organisations
by EEBus Initiative e.V. (such as DKE/DIN-VDE or IEC/CENELEC/ETSI) are versions that have not yet undergone complete testing and can
therefore only be considered as preliminary information. Even versions that have already been published via standardisation organisations
can contain errors and will undergo further improvements and updates in future.
Liability
EEBus Initiative e.V. does not assume liability or provide a guarantee for the accuracy, completeness or up-to-date status of any
specifications, data, documents, publications or other information provided and particularly for the functionality of any developments
based on the above.
Copyright, rights of use and exploitation

The specifications provided are protected by copyright. Parts of the specifications have been submitted to national or international
standardisation organisations by EEBus Initiative e.V., such as DKE/DIN-VDE or IEC/CENELEC/ETSI, etc. Furthermore, all rights to use and/or
exploit the specifications belong to the EEBus Initiative e.V., Deutz-Mülheimer-Straße 183, 51063 Cologne, Germany and can be used in
accordance with the following regulations:
The use of the specifications for informational purposes is allowed. It is therefore permitted to use information evident from the contents
of the specifications. In particular, the user is permitted to offer products, developments and/or services based on the specifications.
Any respective use relating to standardisation measures by the user or third parties is prohibited. In fact, the specifications may only be
used by EEBus Initiative e.V. for standardisation purposes. The same applies to their use within the framework of alliances and/or
cooperations that pursue the aim of determining uniform standards.
Any use not in accordance with the purpose intended by EEBus Initiative e.V. is also prohibited.
Furthermore, it is prohibited to edit, change or falsify the content of the specifications. The dissemination of the specifications in a
changed, revised or falsified form is also prohibited. The same applies to the publication of extracts if they distort the literal meaning of
the specifications as a whole.
It is prohibited to pass on the specifications to third parties without reference to these rights of use and exploitation.
It is also prohibited to pass on the specifications to third parties without informing them of the authorship or source.
Without the prior consent of EEBus Initiative e.V., all forms of use and exploitation not explicitly stated above are prohibited.
Copyright © 2022 EEBus Initiative e.V. All rights reserved. Page 2 of 92

1 Table of contents
2 Table of contents ..................................................................................................................................... 3
3 List of figures ........................................................................................................................................... 4
4 List of tables ............................................................................................................................................ 4
5 1 Scope of the document ................................................................................................................... 7
6 1.1 References ............................................................................................................................... 7
7 1.1.1 EEBUS documents ........................................................................................................... 7
8 1.1.2 Normative references...................................................................................................... 7
9 1.2 Terms and definitions .............................................................................................................. 7
10 1.3 Requirements .......................................................................................................................... 8
11 1.3.1 Requirements wording .................................................................................................... 8
12 1.3.2 Mapping of High-Level requirements.............................................................................. 9
13 2 High-Level description ................................................................................................................... 10
14 2.1 Introduction........................................................................................................................... 10
15 2.2 Detailed background information ......................................................................................... 10
16 2.3 Actors .................................................................................................................................... 11
17 2.3.1 Monitoring Appliance .................................................................................................... 11
18 2.3.2 Battery ........................................................................................................................... 11
19 2.4 Scenarios ............................................................................................................................... 12
20 2.4.1 Scenario 1 - Monitor Battery identification .................................................................. 13
21 2.4.2 Scenario 2 - Monitor Battery state ................................................................................ 14
22 2.4.3 Scenario 3 - Monitor Battery DC power ........................................................................ 15
23 2.4.4 Scenario 4 - Monitor Battery DC current....................................................................... 15
24 2.4.5 Scenario 5 - Monitor Battery DC voltage....................................................................... 16
25 2.4.6 Scenario 6 - Monitor Battery DC energy ....................................................................... 16
26 2.4.7 Scenario 7 - Monitor Battery additional details ............................................................ 17
27 2.4.8 Scenario 8 - Monitor Battery capabilities ...................................................................... 17
28 2.4.9 Scenario 9 - Monitor Battery internal data ................................................................... 18
29 2.5 Dependencies to other Use Cases ......................................................................................... 19
30 2.5.1 "Monitoring of Inverter" ............................................................................................... 19
31 2.6 Further information and rules ............................................................................................... 19
32 2.6.1 Sign conventions............................................................................................................ 19
33 2.6.2 Value state rules ............................................................................................................ 20
34 2.7 Assumptions and Prerequisites ............................................................................................. 20
35 3 Technical SPINE solution ............................................................................................................... 21
36 3.1 General rules and information .............................................................................................. 21
37 3.1.1 Underlying technology documents ............................................................................... 21
38 3.1.2 Use Case discovery rules ............................................................................................... 21
39 3.1.3 Rules for "Content of Specialization..." tables and "Content of Function..." tables ..... 21
40 3.1.4 Rules for "Feature Types and Functions..." tables ........................................................ 31
41 3.1.5 "Actor ... overview" diagram rules ................................................................................ 31
42 3.1.6 Specializations ............................................................................................................... 32
43 3.1.7 Order of messages within the sequence diagrams ....................................................... 33
44 3.1.8 Further information and rules ....................................................................................... 33
45 3.2 Actors .................................................................................................................................... 35
46 3.2.1 Monitoring Appliance .................................................................................................... 35

47 3.2.2 Battery ........................................................................................................................... 55

48 3.3 Pre-Scenario communication ................................................................................................ 74
49 3.3.1 General information ...................................................................................................... 74
50 3.3.2 Detailed discovery ......................................................................................................... 75
51 3.3.3 Binding ........................................................................................................................... 77
52 3.3.4 Subscription ................................................................................................................... 77
53 3.3.5 Dynamic behaviour........................................................................................................ 78
54 3.4 Scenarios ............................................................................................................................... 78
55 3.4.1 Scenario 1-9 - Overall Scenario information ................................................................. 78
56 3.4.2 Scenario 1 - Monitor Battery identification .................................................................. 85
57 3.4.3 Scenario 2 - Monitor Battery state ................................................................................ 85
58 3.4.4 Scenario 3 - Monitor Battery DC power ........................................................................ 86
59 3.4.5 Scenario 4 - Monitor Battery DC current....................................................................... 87
60 3.4.6 Scenario 5 - Monitor Battery DC voltage....................................................................... 87
61 3.4.7 Scenario 6 - Monitor Battery DC energy ....................................................................... 88
62 3.4.8 Scenario 7 - Monitor Battery additional details ............................................................ 89
63 3.4.9 Scenario 8 - Monitor Battery capabilities ...................................................................... 90
64 3.4.10 Scenario 9 - Monitor Internal data ................................................................................ 91
65
66 List of figures
67 Figure 1: High-Level Use Case functionality overview .......................................................................... 10
68 Figure 2: Example for Inverter device-hierarchy ................................................................................... 11
69 Figure 3: Scenario overview .................................................................................................................. 12
70 Figure 4: Actor overview example......................................................................................................... 32
71 Figure 5: Actor "Monitoring Appliance" overview ................................................................................ 35
72 Figure 6: Actor "Battery" overview ....................................................................................................... 55
73 Figure 7: Pre-Scenario communication - Detailed discovery sequence diagram .................................. 76
74 Figure 8: Pre-Scenario communication - Binding sequence diagram ................................................... 77
75 Figure 9: Pre-Scenario communication - Subscription sequence diagram ........................................... 78
76 Figure 10: Scenario 1-9 - Initial Scenario communication sequence diagram ...................................... 80
77 Figure 11: Scenario 1-9 - Runtime Scenario communication sequence diagram ................................. 83
78
79 List of tables
80 Table 1: Scenario implementation requirements for Actors ................................................................ 13
81 Table 2: Scenario 1 - Monitor Battery identification - Data point list ................................................... 13
82 Table 3: Scenario 2 - Monitor Battery state - Data point list ................................................................ 14
83 Table 4: Scenario 3 - Monitor Battery DC power - Data point list......................................................... 15
84 Table 5: Scenario 4 - Monitor Battery DC current - Data point list ....................................................... 15
85 Table 6: Scenario 5 - Monitor Battery DC voltage - Data point list ....................................................... 16
86 Table 7: Scenario 6 - Monitor Battery DC energy - Data point list ........................................................ 16
87 Table 8: Scenario 7 - Battery additional details - Data point list ........................................................... 17
88 Table 9: Scenario 8 - Monitor Battery capabilities - Data point list ...................................................... 18

89 Table 10: Scenario 9 - Monitor Battery internal data - Data point list .................................................. 18
90 Table 11: Presence indication description ............................................................................................ 22
91 Table 12: Example table for cardinality indications on Elements and list items................................... 24
92 Table 13: Content of an example Specialization ................................................................................... 28
93 Table 14: Presence indication of Feature Types and Functions support .............................................. 31
94 Table 15: Specialization support for Actor Monitoring Appliance ........................................................ 36
95 Table 16: Content of Specialization "DeviceClassification_ManufacturerData_MOB" at Actor
96 Monitoring Appliance ............................................................................................................................ 37
97 Table 17: Content of Specialization "DeviceDiagnosis_OperatingState" at Actor Monitoring Appliance
98 ............................................................................................................................................................... 37
99 Table 18: Content of Specialization "Measurement_StateOfCharge" at Actor Monitoring Appliance 39
100 Table 19: Content of Specialization "Measurement_StateOfHealth" at Actor Monitoring Appliance . 40
101 Table 20: Content of Specialization "Measurement_StateOfEnergy" at Actor Monitoring Appliance 41
102 Table 21: Content of Specialization "Measurement_UseableCapacity" at Actor Monitoring Appliance
103 ............................................................................................................................................................... 42
104 Table 22: Content of Specialization "Measurement_DcPower" at Actor Monitoring Appliance ......... 44
105 Table 23: Content of Specialization "Measurement_DcCurrent" at Actor Monitoring Appliance ....... 45
106 Table 24: Content of Specialization "Measurement_DcVoltage" at Actor Monitoring Appliance ....... 46
107 Table 25: Content of Specialization "Measurement_DcChargeEnergy" at Actor Monitoring Appliance
108 ............................................................................................................................................................... 48
109 Table 26: Content of Specialization "Measurement_DcDischargeEnergy" at Actor Monitoring
110 Appliance ............................................................................................................................................... 49
111 Table 27: Content of Specialization "Measurement_LoadCycleCount" at Actor Monitoring Appliance
112 ............................................................................................................................................................... 50
113 Table 28: Content of Specialization "Measurement_ComponentTemperature" at Actor Monitoring
114 Appliance ............................................................................................................................................... 51
115 Table 29: Content of Specialization "DeviceConfiguration_BatteryType" at Actor Monitoring
116 Appliance ............................................................................................................................................... 52
117 Table 30: Content of Specialization "DeviceConfiguration_MaxCycleCountPerDay" at Actor
119 Table 31: Content of Specialization "ElectricalConnection_EntityEnergyCapacityNominalMax" at Actor
121 Table 32: Content of Specialization "ElectricalConnection_EntityPowerConsumptionNominalMax" at
122 Actor Monitoring Appliance .................................................................................................................. 54
123 Table 33: Content of Specialization "ElectricalConnection_EntityPowerProductionNominalMax" at
124 Actor Monitoring Appliance .................................................................................................................. 55
125 Table 34: Specialization support for Actor Battery ............................................................................... 57
126 Table 35: Feature Types and Functions used within this Use Case by the Actor Battery ..................... 58
127 Table 36: Content of Function "deviceClassificationManufacturerData" at Actor Battery .................. 59
128 Table 37: Content of Function "deviceConfigurationKeyValueDescriptionListData" at Actor Battery. 59
129 Table 38: Content of Function "deviceConfigurationKeyValueListData" at Actor Battery ................... 60
130 Table 39: Content of Function "deviceDiagnosisStateData" at Actor Battery ...................................... 60
131 Table 40: Content of Function "electricalConnectionDescriptionListData" at Actor Battery ............... 61
132 Table 41: Content of Function "electricalConnectionParameterDescriptionListData" at Actor Battery
133 ............................................................................................................................................................... 62
134 Table 42: Content of Function "electricalConnectionCharacteristicListData" at Actor Battery ........... 63

135 Table 43: Content of Function "measurementDescriptionListData" at Actor Battery.......................... 65

136 Table 44: Content of Function "measurementConstraintsListData" at Actor Battery .......................... 69
137 Table 45: Content of Function "measurementListData" at Actor Battery ............................................ 74
138 Table 46: Initial Scenario communication content references for Scenario 1-9 ................................... 81
139 Table 47: Runtime Scenario communication content references for Scenario 1-9 .............................. 84
140
141

142 1 Scope of the document

143 This document describes the Use Case "Monitoring of Battery" (short-name: MOB). Chapter 2
144 specifies the High-Level Use Case. Chapter 3 details the technical solution for SPINE for this Use Case.
145 Within this document, a top-down approach is used to derive the requirements for the technical
146 solution from the High-Level description.
147
148 1.1 References
149 1.1.1 EEBUS documents

150 [ProtocolSpecification] EEBus_SPINE_TS_ProtocolSpecification.pdf
151 [ResourceSpecification] EEBus_SPINE_TS_ResourceSpecification.pdf
152 [SHIP] EEBus_SHIP_TS_Specification_v1.0.1.pdf
153
154 1.1.2 Normative references

155 [RFC2119] IETF RFC 2119: 1997, Key words for use in RFCs to indicate requirement levels
156 Please see section 1.3.1 for details.
157
158 1.2 Terms and definitions

159 Actor
160 An Actor models a role within a Use Case definition (e.g. an energy manager or an electric vehicle).
161 AC
162 Abbreviation for alternating current.
163 Active sign convention

164 An electrical current is positive if the current is flowing out of device or component. In this case, the
165 device or component produces electrical power and the active power is greater than zero. An
166 electrical current is negative if the current is flowing into a device or component. In this case, the
167 device or component consumes electrical power and the active power is smaller than zero.
168 CEM
169 Abbreviation for Customer Energy Manager. The CEM is an energy manager located at the user's
170 home or premises or in a cloud application. The energy manager enables energy-optimized operation
171 of the connected devices by harmonizing energy demand and availability.
172 DC
173 Abbreviation for direct current.
174 EV
175 Abbreviation for electric vehicle.
176 HVAC
177 Abbreviation for heating, ventilation and air conditioning.

178 MOB
179 Monitoring of Battery (short-name of this Use Case)
180 Monitoring Appliance

181 The Actor Monitoring Appliance evaluates particular data of another Actor.
182 Passive sign convention

183 An electrical current is positive if the current is flowing into a device or component. In this case, the
184 device or component consumes electrical power and the active power is greater than zero. An
185 electrical current is negative if the current is flowing out of a device or component. In this case, the
186 device or component produces electrical power and the active power is smaller than zero.
187 PV
188 Abbreviation for photovoltaic.
189 PV String
190 Several PV modules are connected in groups parallel to the inverter. A group of modules connected
191 in series is called a PV string.
192 Scenario
193 Part of a Use Case. Splitting a Use Case into Scenarios helps to understand the Use Case more
194 quickly. Some Scenarios are mandatory for a Use Case, whereas others may be recommended or
195 optional.
196 Specialization
197 Reusable data collection for a specific functionality.
198 SPINE
199 Smart Premises Interoperable Neutral-message Exchange: Technical Specification of EEBus Initiative
200 e.V.
201 UI
202 Abbreviation for user interface.
203 UTC
204 Abbreviation for Coordinated Universal Time.
205
206 1.3 Requirements
207 1.3.1 Requirements wording

208 The following keywords are used:
209 - SHALL
210 - SHALL NOT
211 - SHOULD
212 - SHOULD NOT
213 - MAY
214 Note: They apply only if written in capital letters.

215 For the meaning of the keywords, please refer to [RFC2119].
216
217 1.3.2 Mapping of High-Level requirements

218 Within the High-Level Use Case description, the following abbreviation is used:
219 [MOB-xyz]
220 e.g.: [MOB-007]
221 The abbreviation is used to mark High-Level requirements or rules of this Use Case with a unique
222 number xyz. These requirements are referenced throughout the technical solution to show how each
223 High-Level requirement is realized in the technical part.
224

225 2 High-Level description
226 2.1 Introduction

227 Electrical storage systems are essential to realize the energy transition, as they enable power
228 generation to be independent of consumption. On the one hand the mobility transition and CO2
229 saving goal bring new large loads like electric vehicles (EVs) and heating, ventilation and air
230 conditioning (HVAC) systems to buildings, on the other hand the energy transition leads into much
231 more use of fluctuating energy like wind or photovoltaic (PV).
232 The growing share of electric vehicles further increases the need for electrical storage systems to
233 enable recharging independent of the availability of electrical grid energy. Faster recharging of an EV
234 or even nearly free of charge recharging through PV energy that was not power curtailed during the
235 day will be enabled at reduction of load on the public electricity grid at the same time.
236 An electrical storage system (in the following called battery) is charged and discharged with direct
237 current (DC). To integrate the battery into the local or public electricity grid, an inverter is needed
238 that converts the direct current into alternating current (AC).
239 A client, e.g. a customer energy manager (CEM) or a user interface (UI), may monitor data such as
240 identification information, the state of the battery, power/current/voltage, or nominal values.
Measured values and

additional information
CEM
Battery
Monitoring
Inverter Appliance
241
242 Figure 1: High-Level Use Case functionality overview
243 The retrieved data may be used for energy management purposes, debugging, or to just visualize the
244 data to the customer. Some examples are given in the following list:
245 - Optimization of self-consumption

246 - Increase of autarky rate
247 - Appliance identification
248 - Efficiency calculation
249 - Error detection
250
251 2.2 Detailed background information

252 This Use Case describes a battery's data in context of a hybrid or battery inverter.

Photovoltaic Hybrid Battery

Inverter Inverter Inverter
1 1 1
Inverter
0..n 1..m
0..n 1..m
PV String Battery
253
254 Figure 2: Example for Inverter device-hierarchy
255 The context of the Inverter is given by its so-called "parent" in the device-hierarchy ([MOB-004]). This
256 can be:
257 - "Hybrid Inverter" ([MOB-004/1]), meaning that the Inverter is a hybrid Inverter that has both
258 PV Strings (up to "n" in Figure 2) and Batteries (up to "m" in Figure 2) as "children" in its
259 device hierarchy
260 - "Battery Inverter" ([MOB-004/2]), meaning that the Inverter has (at least) one Battery as
261 "child" in its device hierarchy.
262 - Note: Other Use Cases may also specify a "Photovoltaic Inverter", where the Inverter has
263 only PV Strings as so-called "children" in its device hierarchy. This type of Inverter is not
264 considered in this Use Case.
265 Note: The "0..n" of Figure 2 just expresses that this Use Case does neither require nor describe data
266 of any PV String itself, as such information is covered by PV String specific Use Cases. Instead, this
267 Use Case covers information of an attached Battery.
268
269 2.3 Actors
270 2.3.1 Monitoring Appliance

271 The Actor Monitoring Appliance (e.g., a CEM) can manage the home's appliances to ensure energy-
272 optimized operation of the appliances or visualize the information. In this Use Case, the Monitoring
273 Appliance retrieves data provided by a Battery via a Hybrid or Battery Inverter.
274
275 2.3.2 Battery

276 The Battery is a sub-device of the Inverter. It represents one Battery that can store or release energy
277 (in form of DC power).

278
279 2.4 Scenarios
280
281 Figure 3: Scenario overview

282
Scenario number
Scenario name
Monitoring
Appliance
Battery
1 Monitor Battery identification M R*1
2 Monitor Battery state M M
3 Monitor Battery DC power R M
4 Monitor Battery DC current M M
5 Monitor Battery DC voltage M M
6 Monitor Battery DC energy M R
7 Monitor Battery additional details R R
8 Monitor Battery capabilities R M
9 Monitor Battery internal data O O
283 Table 1: Scenario implementation requirements for Actors
284 *1: Scenario 1 ist not mandatory for the Actor Battery, as there might be installations where the
285 Battery's parent device (see section 2.2) is not capable of providing identification information for the
286 Battery.
287
288 2.4.1 Scenario 1 - Monitor Battery identification
289 2.4.1.1 Description

290 This Scenario is used to identify the Actor Battery. Depending on the information provided by the
291 Inverter, several data points are available to be requested by the Actor Monitoring Appliance.
Data point name Data point description Support High-Level

indication requirement
Device Name Name of the Battery part as indicated on the R [MOB-011]
packaging.
Device Code Code of the Battery part to uniquely identify R [MOB-012]
the exact model.
Serial Number Unique serial number of the Battery part. R [MOB-013]
Software Revision Version of the software on the Battery part. R [MOB-014]
Hardware Revision Hardware version of the Battery part. R [MOB-015]
Manufacturer Name Name of the manufacturer of the Battery part. M [MOB-016]
Battery Label Label for the Battery part (e.g. for display O [MOB-017]
purposes).
292 Table 2: Scenario 1 - Monitor Battery identification - Data point list
293
294 2.4.1.2 Conditions

295 Triggering Event:
296 The Actor Monitoring Appliance connects to the Actor Battery.

297 Pre-condition:
298 The Actor Monitoring Appliance does not know the Battery's identification information.
299 Post-condition:
300 The Actor Monitoring Appliance knows the identification information provided by the Actor Battery.
301
302 2.4.2 Scenario 2 - Monitor Battery state

304 The state values of the Actor Battery are provided by this Scenario. The following data points can be
305 provided by the Battery:

Battery State of Charge Current state of charge in percentage of M [MOB-021]
the "Battery Usable Capacity" ([MOB-
024]).
Battery State of Health Current state of health in percentage of R [MOB-022]
"Battery Capacity Nominal Max" ([MOB-
081]).
Battery State of Energy Remaining energy of the Battery in Wh. R [MOB-023]
Battery Usable Capacity Usable part of the capacity of the Battery R [MOB-024]
in Wh.
Battery State State of the Battery. M [MOB-025]
Possible states:
- Normal operation [MOB-025/1]
- Standby [MOB-025/2]
- Temporarily not ready [MOB-
025/3]
- Off [MOB-025/4]
- Failure [MOB-025/5]
306 Table 3: Scenario 2 - Monitor Battery state - Data point list
307 This specification defines the following relations:
308 1. "Battery Usable Capacity" ([MOB-024]) = "Battery Capacity Nominal Max" ([MOB-081]) * "Battery
309 State of Health" ([MOB-022])
310 2. "Battery State of Energy" ([MOB-023]) = "Battery Usable Capacity" ([MOB-024]) * "Battery State
311 of Charge" ([MOB-021])
312 Note: The data points and their relations describe ideal conditions. In practice, external conditions
313 (temperature or magnitude of a discharge power, e.g.) as well as internal conditions (intrinsic
314 limitations on measurement accuracy, curtailment of discharge level, etc.) may lead to inaccuracies.
315

318 The Actor Monitoring Appliance is interested in the state values of the Actor Battery.

319 Pre-condition:
320 The Actor Monitoring Appliance does not know the state values of the Actor Battery.
321 Post-condition:
322 The Actor Monitoring Appliance knows the state values of the Actor Battery.
323
324 2.4.3 Scenario 3 - Monitor Battery DC power

326 The DC power values of the Actor Battery are provided by this Scenario. The following data points
327 can be provided by the Battery:

Battery DC Power DC power of the Battery. M [MOB-031]
328 Table 4: Scenario 3 - Monitor Battery DC power - Data point list
329

332 The Actor Monitoring Appliance is interested in the DC power values of the Actor Battery.
333 Pre-condition:
334 The Actor Monitoring Appliance does not know the DC power values of the Actor Battery.
335 Post-condition:
336 The Actor Monitoring Appliance knows the DC power values of the Actor Battery.
337
338 2.4.4 Scenario 4 - Monitor Battery DC current

340 The DC current values of the Actor Battery are provided by this Scenario. The following data points

Battery DC Current DC current of the Battery. M [MOB-041]
342 Table 5: Scenario 4 - Monitor Battery DC current - Data point list
343

346 The Actor Monitoring Appliance is interested in the DC current values of the Actor Battery.
347 Pre-condition:
348 The Actor Monitoring Appliance does not know the DC current values of the Actor Battery.

349 Post-condition:
350 The Actor Monitoring Appliance knows the DC current values of the Actor Battery.
351
352 2.4.5 Scenario 5 - Monitor Battery DC voltage

354 The DC voltage values of the Actor Battery are provided by this Scenario. The following data points

Battery DC Voltage DC voltage of the Battery. M [MOB-051]
356 Table 6: Scenario 5 - Monitor Battery DC voltage - Data point list
357

360 The Actor Monitoring Appliance is interested in the DC voltage values of the Actor Battery.
361 Pre-condition:
362 The Actor Monitoring Appliance does not know the DC voltage values of the Actor Battery.
363 Post-condition:
364 The Actor Monitoring Appliance knows the DC voltage values of the Actor Battery.
365
366 2.4.6 Scenario 6 - Monitor Battery DC energy

368 The DC energy values of the Actor Battery are provided by this Scenario. The following data points

Battery Total DC Total amount of energy that was charged into the M [MOB-061]
Charge Energy Battery. Accumulated over lifetime or since last
reset.
Battery Total DC Total amount of energy that was discharged from M [MOB-062]
Discharge Energy the Battery. Accumulated over lifetime or since
last reset.
370 Table 7: Scenario 6 - Monitor Battery DC energy - Data point list
371

374 The Actor Monitoring Appliance is interested in the DC energy values of the Actor Battery.

375 Pre-condition:
376 The Actor Monitoring Appliance does not know the DC energy values of the Actor Battery.
377 Post-condition:
378 The Actor Monitoring Appliance knows the DC energy values of the Actor Battery.
379
380 2.4.7 Scenario 7 - Monitor Battery additional details

382 Some additional values of the Actor Battery are provided by this Scenario. The following data points
383 are specified:

Cumulated Load Number of full charge/discharge cycles*1 of O [MOB-071]
Cycle Count the Battery since installation (or last reset).
Battery Type Type of the Battery. Possible types are: O [MOB-072]
- Lithium-ion [MOB-072/1]
- Lead-acid [MOB-072/2]
- Redox flow [MOB-072/3]
- Sodium-ion [MOB-072/4]
384 Table 8: Scenario 7 - Battery additional details - Data point list
385 *1: Even though the Cumulated Load Cycle Count is an integer value, the Inverter should internally
386 count partial charge/discharge cycles with an according fraction. This is a vendor specific
387 implementation.
388 Note: If this Scenario is supported, at least one of the values stated above SHALL be supported.
389

392 The Actor Monitoring Appliance is interested in the additional detail values of the Actor Battery.
393 Pre-condition:
394 The Actor Monitoring Appliance does not know about the additional detail values of the Actor
395 Battery.
396 Post-condition:
397 The Actor Monitoring Appliance knows the additional detail values of the Actor Battery.
398
399 2.4.8 Scenario 8 - Monitor Battery capabilities

401 The capability information of the Actor Battery is provided by this Scenario. The following data points


Battery Capacity The nominal capacity of the Battery in Wh as M [MOB-081]
Nominal Max specified in the manufacturer's data sheet.
For the usable part of the capacity of the
Battery see [MOB-024].
Battery DC Charge The nominal maximum DC power the Battery R [MOB-082]
Power Nominal Max can be charged with, as specified in the
manufacturer's data sheet.
For the measured value see [MOB-031].
Battery DC Discharge The nominal maximum DC power the Battery R [MOB-083]
Power Nominal Max can be discharged with, as specified in the
manufacturer's data sheet.
For the measured value see [MOB-031].
Battery Maximum Maximum number of cycles the battery O [MOB-084]
Charge/Discharge permits per day.
Cycle Count Per Day
403 Table 9: Scenario 8 - Monitor Battery capabilities - Data point list
404

407 The Actor Monitoring Appliance is interested in the capability information of the Actor Battery.
408 Pre-condition:
409 The Actor Monitoring Appliance does not know the capability information of the Actor Battery.
410 Post-condition:
411 The Actor Monitoring Appliance knows the capability information of the Actor Battery.
412
413 2.4.9 Scenario 9 - Monitor Battery internal data

415 Some internal data of the Actor Battery are provided by this Scenario. The following data points are
416 specified:

Internal Internal component temperature. It is not O [MOB-091]
Temperature specified further where the temperature
sensor is located within the Actor.
417 Table 10: Scenario 9 - Monitor Battery internal data - Data point list
418 Note: If this Scenario is supported, at least one of the values stated above SHALL be supported.
419

422 The Actor Monitoring Appliance is interested in the internal data of the Actor Battery.

423 Pre-condition:
424 The Actor Monitoring Appliance does not know the internal data of the Actor Battery.
425 Post-condition:
426 The Actor Monitoring Appliance knows the internal data of the Actor Battery.
427
428 2.5 Dependencies to other Use Cases
429 2.5.1 "Monitoring of Inverter"

430 The Use Case "Monitoring of Inverter" describes the information provided by the Actor Inverter.
431 The Actor Inverter as parent Actor of the Actor Battery of this Use Case (see section 2.2) SHALL
432 support the Use Case "Monitoring of Inverter".
433 The Actor Monitoring Appliance SHALL support the Use Case "Monitoring of Inverter".
434
435 2.6 Further information and rules
436 2.6.1 Sign conventions

437 Throughout the whole Use Case the "load convention" (i.e. "passive sign convention") is applied for
438 measurement values ([MOB-001]). This means measured electrical current, active power and
439 exchanged energy are expressed with positive values in case of energy consumption whereas
440 negative values are used in case of energy production. This holds valid for the following values of this
441 Use Case:
442 - Battery DC Power ([MOB-031])

443 - Battery DC Current ([MOB-041])
444 - Battery Total DC Charge Energy ([MOB-061])
445 - Battery Total DC Discharge Energy ([MOB-062])
446 The Battery's voltage ([MOB-051]) is measured independent of the energy direction ([MOB-002/1]).
447 Percentage values are always expressed as non-negative value between 0 and 100 ([MOB-002/2]).
448 This holds valid for the following values of this Use Case:
449 - Battery State of Charge ([MOB-021])

450 - Battery State of Health ([MOB-022])
451 The data points that indicate energy capacities of the Battery are always expressed as non-negative
452 value ([MOB-002/3]). This holds valid for the following values of this Use Case:
453 - Battery State of Energy ([MOB-023])

454 - Battery Usable Capacity ([MOB-024])
455 - Battery Capacity Nominal Max ([MOB-081])

456 The sign convention described above does NOT apply to nominal values. For nominal values that are
457 dedicated to a particular energy direction it is common practice to express them as positive value.
458 Their name indicates whether they are used for consumption or production direction ([MOB-003]):
459 - Battery DC Charge Power Nominal Max ([MOB-082]): consumption direction

460 - Battery DC Discharge Power Nominal Max ([MOB-083]): production direction
461
462 2.6.2 Value state rules

463 Each Battery's measurement value has a state that defines whether the value is correct or is to be
464 ignored by the Monitoring Appliance ([MOB-005]):
465 - normal: value correct

466 - out of range: value is out of range and SHALL be ignored by the Monitoring Appliance
467 - error: value is erroneous and SHALL be ignored by the Monitoring Appliance.
468
469 2.7 Assumptions and Prerequisites

470 None.
471

472 3 Technical SPINE solution
473 3.1 General rules and information
474 3.1.1 Underlying technology documents

475 This technical solution relies on the SPINE Resources Specification version 1.2.0
476 [ResourceSpecification].
477 For interoperable connectivity this technical solution relies on:
478 - SPINE Protocol Specification version 1.2.0 [ProtocolSpecification] as application protocol.

479 - SHIP Specification version 1.0.1 [SHIP] as transport protocol.
480
481 3.1.2 Use Case discovery rules

482 Use Case discovery SHALL be supported by each Actor and the following rules SHALL apply:
483 - The string content for the Element "nodeManagementUseCaseData. useCaseInformation.

484 useCaseSupport. useCaseName" within the Use Case discovery (please refer to
485 [ProtocolSpecification]) SHALL be "monitoringOfBattery". The string content SHALL only be
486 defined by this Use Case (regardless of the Use Case version).
487 - The string content of the Element "nodeManagementUseCaseData. useCaseInformation.
488 actor" within the Use Case discovery (please refer to [ProtocolSpecification]) SHALL be set to
489 the according value stated within the corresponding Actor's section.
490 - An Actor A that is implemented to support this Use Case specification SHALL set the Element
491 "nodeManagementUseCaseData. useCaseInformation. useCaseSupport. useCaseVersion"
492 within the Use Case discovery (please refer to [ProtocolSpecification]) to "1.0.0".
493 - If an Actor A supports multiple versions of this Use Case with the same major version
494 number, only the highest one SHOULD be set within the Use Case discovery.
495 - If an Actor A finds a proper counterpart Actor B for this Use Case that supports multiple
496 versions of this Use Case with the same major version number as supported by Actor A, the
497 Actor A SHOULD evaluate from these versions of Actor B only the highest version number.
498 - If an Actor A supports multiple versions of this Use Case with different major version
499 numbers, for each major version number only the highest version number SHOULD be set
500 within the Use Case discovery.
501 - If an Actor A finds a proper counterpart Actor B for this Use Case that supports only versions
502 with a major version number not implemented by Actor A, it still might be possible to run the
503 Use Case or parts of the Use Case. Therefore, the Actor A should try to evaluate the Actor B
504 as a valid partner for this Use Case.
505
506 3.1.3 Rules for "Content of Specialization..." tables and "Content of Function..." tables
507 3.1.3.1 General presence indication definitions

508 Abbreviations for the presence indication of Elements listed in the tables are defined as follows:
Abbreviation Meaning Link to requirement keywords

M Mandatory SHALL
R Recommended SHOULD
O Optional MAY
509 Table 11: Presence indication description
510 An Actor MAY support Elements that are not listed in the tables. However, another Actor MAY ignore
511 these Elements.
512 The presence indications "M", "R" and "O" are always meant relative to the respective parent
513 Element. I.e. if a parent Element is optional ("O") and a child is mandatory ("M") the child Element
514 can only be present if the parent Element is present as well.
515 Note: The indications and the aforementioned rules apply for "complete messages" (so-called "full
516 function exchange", please refer to [ProtocolSpecification]). In contrast, the so-called "restricted
517 function exchange" is designed to permit exchange of specific excerpts of data, i.e. fewer Elements
518 than potentially available from the data owner (partially even not all "mandatory" Elements).
519
520 3.1.3.2 Presence indications for "Content of Specialization..." tables

521 This section only defines rules for the client side.
522 Elements that are marked with "M" SHALL be supported by the client in case of readable as well as
523 writeable data. This Element may be optional on the server side.
524 The following applies for readable data that is exchanged in a "read/reply" or "notify" operation:
525 - "R" means that the data SHOULD be supported by the client. In other words: If the server
526 responds with the according Element, the client SHOULD be able to interpret the according
527 Elements.
528 - "O" means that the data MAY be supported by the client. In other words: If the server
529 responds with the according Element, the client MAY be able to interpret the according
530 Elements.
531 The following applies for writeable data that is exchanged in a "write" operation:
532 - "R" means that the data SHOULD be written by the client.
533 - "O" means that the data MAY be written by the client.
534 - "F" means that the data SHALL NOT be written by the client.
535 The following applies for Elements that are not listed in the Actor section:
536 - In case of a received "reply" message: The client MAY ignore the Element.
537 - In case of a "write" operation to be created: The client MAY set the Element but SHALL
538 consider that the server may ignore the Element.
539 - In case of a received "notify" message: The client MAY ignore the Element.
540 M, R or O may be combined with the suffix "(event)" to express that a supported Element or value
541 only has to be supported during a certain event and hence does not need to be present at all times. If
542 the event is not active the Element may be omitted or another value may be set. In most cases a
543 High-Level requirement reference for the event is given in the rules column.

544 In some cases, an Element may have a double presence indication, separated by a colon. Examples:
545 - M, O
546 - M \W, O \W
547 The description (rules) of the Element details in such a case the presence requirement. A typical
548 example is a list-based Element where the "first" (or "last") Element has a different presence
549 requirement than the other list Elements.
550
551 3.1.3.3 Presence indications for "Content of Function..." tables

552 This section only defines rules for the server side.
553 Elements that are marked with "M" SHALL be supported by the server in case of readable as well as
554 writeable data. In case of writeable data (marked with "M \W") the server does not need to set the
555 Element, because the Element is set only by the client.
556 The following applies for readable data that is exchanged in a "read/reply" or "notify" operation:
557 - "R" means that the data SHOULD be provided by the server.
558 - "O" means that the data MAY be provided by the server.
559 - "F" means that the data SHALL NOT be provided by the server.
560 The following applies for writeable data that is exchanged in a "write" operation:
561 - "R" means that the data SHOULD be supported. In other words: If the client writes the
562 Element, the server SHOULD accept those messages and the contained Elements.
563 - "O" means that the data MAY be supported. In other words: If the client writes the Element,
564 the server MAY accept those messages and the contained Elements.
565 The following applies for Elements that are not listed in the Actor section:
566 - In case of a received "read" request: The according Element MAY be set in the reply.
567 - In case of a received "write" operation: The server MAY ignore the Element.
568 - In case of a "notify" operation to be created: The server MAY set the Element.
569 Note: The server will only accept write operations if the result fulfils the server Function
570 requirements (permitted values, e.g.). Write operations on Elements that are not writeable MAY
571 result in an error message.
572 M, R or O may be combined with the suffix "(event)" to express that a supported Element or value
573 only has to be supported during a certain event and hence does not need to be present at all times. If
574 the event is not active the Element may be omitted or another value may be set. In most cases a
575 High-Level requirement reference for the event is given in the rules column.
576 In some cases, an Element may have a double presence indication, separated by a colon. Examples:
577 - M, O
578 - M \W, O \W

579 The description (rules) of the Element details in such a case the presence requirement. A typical
580 example is a list-based Element where the "first" (or "last") Element has a different presence
581 requirement than the other list Elements.
582
583 3.1.3.4 Cardinality indications on Elements and list items

584 A cardinality indication on an Element or list item expresses constraints on the number of
585 occurrences of a given Element or data set. In this section we use "X" as representation for such an
586 Element or data set. Furthermore, "a" and "b" represent constraints. The following rules apply for
587 the occurrence of "X" and its content related to a specific Scenario (see note underneath the list):
588 1. X
589 No cardinality indication.
590 2. X (a..b)
591 This means "X" SHALL occur at least "a" times and at maximum "b" times.
592 3. X (a..)
593 This means "X" SHALL occur at least "a" times and MAY occur more than "a" times.
594 4. X (..b)
595 This means "X" SHALL occur at maximum "b" times and MAY occur less than "b" times (even
596 zero occurrences are permissive).
597 Note: These rules apply only under consideration of presence indications and with regards to the
598 given Scenario or Function definition for this Use Case.
599 The following table is an example to explain this for two different placements.
Element and value
M/R/O [\W][\C]
Scenario [{...}]:
[High-Level
Mapping]
Element
Value
rules
... ... ...

2: M \W xFeatureType. xListData. xData. (1..3)
2: M \W xId <*#(1..)> PRIMARY IDENTIFIER
2: M \W timePeriod ...
2: M \W timePeriod. startTime <xs:duration>
2: M \W xSlot. (1..)
2: M \W xSlot. xSlotId ...
2: M \W xSlot. duration <xs:duration> ...
... ... ... ...
600 Table 12: Example table for cardinality indications on Elements and list items
601 The field
602 xFeatureType. xListData. xData. (1..3)
603 introduces a data pattern (required Elements and values) for "xData" instances used for Scenario 2.
604 The field itself specifies that such an "xData" instance SHALL occur at least 1 time and at maximum 3

605 times within "xListData" of Feature Type "xFeatureType". However, this constraint holds only for
606 Scenario 2 and only if such "xData" are required. In this case, they are required, as the left field
607 2: M \W
608 denotes that this data set is mandatory for Scenario 2.
609 The field
610 xSlot. (1..)
611 expresses that the Element "xSlot" SHALL occur at least one time within its "xData", but MAY occur
612 more than one time.
613 For the expression "<*#(1..)>" of Element "xId" please see section 3.1.3.6.
614 The remaining fields do not have an explicit cardinality indication.
615 Note: Cardinality expressions are also used within placeholder expressions as defined in section
616 3.1.3.6. In many cases such placeholder expressions define the number of required or permitted
617 Elements or list items as they explicitly define how many different values for a given Identifier are
618 required or permitted for a given Scenario.
619
620 3.1.3.5 Writability and changeability indication

621 In the same column where the presence indications are denoted, a mark is used to distinguish
622 between writeable, changeable or readable Elements:
623 - Elements that are marked with "\W" are written by a client and SHALL be writeable at the
624 server according to their presence indications. The client is not obliged to read the according
625 data. Received notifications do not need to be evaluated.
626 - Elements that are marked with "\C" are changed by a client and SHALL be changeable at the
627 server according to their presence indications. The client is not obliged to read the according
628 data. Received notifications do not need to be evaluated.
629 - Elements that are marked with "\RW" are read and written by a client and SHALL be
630 writeable and provided by the server according to their presence indications. Received
631 notifications SHALL be evaluated according to their presence indications.
632 - Elements that are marked with "\RC" are read and changed by a client and SHALL be
633 changeable and provided by the server according to their presence indications. Received
634 notifications SHALL be evaluated according to their presence indications.
635 - Elements that are not marked are only read by a client and SHALL be provided by the server
636 according to their presence indications. Received notifications SHALL be evaluated according
637 to their presence indications.
638 "Writeable" means that the Element and its value may be written by a client. This includes the
639 possibility to modify (if the Element is already present), create (if the Element is not present yet), and
640 delete the Element. The server SHALL adjust its Function according to the received "write" operation
641 (unless the server cannot accept the "write" operation according to section 3.1.3.3).

642 "Changeable" means that the Element's value may be changed by a client. If the Element is not
643 present at the resource before, it probably cannot be created by the client via the "write" operation.
644 In this case the server MAY decline such a message.
645 Note: "\W" includes "\C" already.
646 Note: Depending on the resource a client might need to request a proper binding before the server
647 accepts a "write" operation.
648
649 3.1.3.6 "Value" placeholders
650 3.1.3.6.1 Introduction

651 Specializations may use placeholders to model relations between different Elements or even list
652 items of different Functions. The main purpose is to declare which Identifier values relate to each
653 other. As a Use Case does not prescribe specific values to be used for a given Identifier, a placeholder
654 like "<x1>" can be used in "Value" columns to express the intended relations.
655 There are two styles to identify a placeholder that can be referenced:
656 1. <xM>
657 2. <xM#S>
658 where
659 1. "x" is any alphabetical prefix like "m", "t", "ec", "cc", etc.
660 2. "M" is a (major) number like "1", "2", "15", etc.
661 3. "S" is a sub-number like "1", "7", "10", etc.
662 Examples for the first style are "<ec1>", "<z12>". Examples for the second style are "<p4#2>",
663 "<m22#3>". For a given placeholder, only one of the styles can be used.
664 In addition, there are also styles for placeholders that do not need to be referenced:
665 1. <*>
666 2. <*#S>
667 The second style is only used with so-called cardinality expressions.
668
669 3.1.3.6.2 Uniqueness of placeholders

670 A given placeholder <xM> or <xM#S> represents the same value throughout a given Use Case
671 specification for a given set of its parent Identifier values. This shall be explained in a brief example:
672 We assume a list item with PRIMARY IDENTIFIER "pId". It also has a SUB IDENTIFIER "sId" with
673 placeholder "<s1>". Then, each occurrence of "<s1>" represents the same value for a given value of
674 pId. This means that "<s1>" of a list item with pId=1 can differ from "<s1>" of a list item with pId=2.
675 But it also means that "<s1>" represents the same value in all list items with pId=1.

676 Note: Typically, parent Identifiers like "pId" will also be expressed with a placeholder like "<p5>", e.g.
677 In this case, the uniqueness rule applies for "<p5>" likewise.
678 Note: The uniqueness also applies for placeholders used as FOREIGN IDENTIFIER.
679
680 3.1.3.6.3 Placeholder expressions with cardinalities

681 For some Identifiers, more than one placeholder is needed. Several notations are used for this
682 purpose, which make use of cardinality expressions. The general notation is as follows:
683 1. <xM#(a..b)>
684 This is equivalent to this explicit definition:
685 At least a and at maximum b placeholders of this list: <xM#1> <xM#2> ... <xM#b>
686 This means that the implementation of a given Use Case (or Scenario) requires a minimum of "a"
687 distinct values of the respective Identifier. In total, there can be up to "b" distinct values of the
688 respective Identifier.
689 Additionally, the following notations may occur:
690 2. <xM#(a..)>
691 This is equivalent to "<xM#(a..b)>" with "b" equal to infinity.
692 3. <xM#(..b)>
693 This is equivalent to "<xM#(a..b)>" with "a" equal to zero.
694 "<xM#(a..)>" has only a lower bound of "a" distinct values, but no upper bound. "<xM#(..b)>", on the
695 other hand, expresses that the Identifier may not be required at all, but it is permitted to have up to
696 "b" distinct values.
697 Similarly, the cardinality can be used for placeholders that are not referenced, i.e. <*#(a..b)> etc.
698 Note: The cardinality does NOT express which of the sub-numbers have to be used! I.e., it does NOT
699 mean that the Identifiers <xM#1> ... <xM#a> are always used and just those with larger sub-numbers
700 (<xM#a+1> ... <xM#b>) are optional. If, for instance, a placeholder expression "<xM#(3..5)>" is given,
701 it may well happen that an implementation makes use of <xM#2>, <xM#4>, and <xM#5> (i.e., it does
702 NOT use <xM#1>, <xM#3>). Which sub-numbers are used usually depends on other parts of a
703 Specialization and their references to required placeholders, which is explained in section 3.1.3.6.4.
704
705 3.1.3.6.4 References to placeholders and relations

706 According to the styles for placeholders that can be referenced, an enumeration value "e" can refer
707 to a particular placeholder:
708 1. e(-><xM>)
709 2. e(-><xM#S>)
710 This denotes that "e" is to be used with "<xM>" or "<xM#S>", resp.

711 Example: A Specialization contains the Elements "mId" and "phase". "mId" is an Identifier with
712 placeholder definition <m2#(1..3)>. "phase" is a string that permits the values "a", "b", and "c" using
713 this expression:
714 "a"(-><m2#1>)
715 "b"(-><m2#2>)
716 "c"(-><m2#3>)
717 This expresses that the enumeration value "a" is to be used with the placeholder <m2#1>, "b" is to
718 be used with <m2#2> and "c" with <m2#3>.
719 Similarly, a placeholder "yN" can refer to a particular placeholder:
720 3. <yN->xM>
721 4. <yN->xM#S>
722 5. <yN#T->xM>
723 6. <yN#T->xM#S>
724 where "T" is a sub-number of "yN".
725 It is also feasible to associate placeholders with cardinalities:
726 7. <yN#(a..b)->xM#(a..b)>
727 denotes that <yN#1> is to be used with <xM#1>, <yN#2> is to be used with <xM#2>, etc.
728 Note: In this case, the placeholder expressions of yN and xM must have the same cardinality.
729 In some cases, there is a need to express that multiple list items with similar values are feasible or
730 required, but only particular combinations of these different data are permitted. The following
731 example shows that several "fData" list items with different "phase" value are required, but that
732 these list items may only express either the "phase" value combination { "a", "b", "c" } or the "phase"
733 value combination { "a", "abc", "neutral" }. The permitted combinations are defined in a note below a
734 table:
M/R/O [\W][\C]
Scenario [{...}]:
Element and
[High-Level
value rules
Mapping]
Element
Value
2: M F. fListData. fData.
2: M zId <z3#(3..5)>
2: M phase "a"(-><z3#1>)
"b"(-><z3#2>)
"c"(-><z3#3>)
"abc"(-><z3#4>)
"neutral"(-><z3#5>)
735 Table 13: Content of an example Specialization

736 Note: One of the following combinations SHALL be used at least: {<z3#1>, <z3#2>, <z3#3>} or
737 {<z3#1>, <z3#4>, <z3#5>}.
738
739 3.1.3.7 Rules for content of "Value" column

740 For a given Scenario, the "Value" column may restrict the permitted content of a Function's Element
741 to one or more particular values. This means that Elements with values deviating from the restriction
742 (i.e. from the permitted values) do not belong to the respective Scenario and need to be considered
743 as if the Element is not set. If more than one particular value is permitted for an Element, the values
744 are in a single line each.
745 If a presence indication is set for the value (in an additional column before the value), the following
746 rules SHALL be applied:
747 - "M" means that the value SHALL be supported. This means the value needs to be set at a
748 certain point in time (depending on the value rules) or for a certain Element within a list
749 entry.
750 - "R" means that the value SHOULD be supported.
751 - "O" means that the value MAY be supported.
752 If all possible values of a given mandatory Element are optional or recommended and this Element is
753 used for the purpose of the respective Scenario, one of the values SHALL be set. If all possible values
754 of a given optional or recommended Element are optional or recommended, this Element MAY
755 contain also other values, but then this Element SHALL NOT be considered as part of the respective
756 Scenario.
757 M, R or O may be combined with the suffix "(event)" to express that a supported value only has to be
758 supported during a certain event and hence does not need to be present at all times. If the event is
759 not active another value may be set. In most cases a High-Level requirement reference for the event
760 is given in the rules column.
761 If no presence indication is set for the value, the following rules SHALL be applied:
762 - In case of Elements where the server may set or change an Element on its own (see section
763 3.1.3.5):
764 o within the tables in the "Server data - Resources" sections:
765 ▪ the server SHALL support at least one of the listed values.
766 o within the tables in the "Client data - Specializations" sections:
767 ▪ the client SHALL support all listed values.
768 - In case of Elements that are writeable or changeable (see section 3.1.3.5):
769 o within the tables in the "Server data - Resources" sections:
770 ▪ the server SHALL support all listed values.
771 o within the tables in the "Client data - Specializations" sections:
772 ▪ the client SHALL support at least one of the listed values.
773 Depending on the Element, different values may be used during runtime. If this is the case, those
774 rules are described within the value rules.

775 If a value is placed in parenthesis, the corresponding value is a recommendation. The actual value
776 MAY deviate from this, e.g. "(1024)".
777
778 3.1.3.8 General information on how to interpret the "Content of Function..." and "Content of
779 Specialization..." tables
780 Within the "Client data - Specializations" sections each Specialization is described in an own sub-
781 section with the name "Specialization "<name of the Specialization>"" (e.g. "Specialization
782 "Measurement_GridFeedInEnergy""). It contains only one table that includes all Elements needed for
783 this Specialization. The different Functions are mentioned in a continuous row, highlighted with grey
784 background colour. This row contains the following parts:
785 <Feature Type>. <Function>.[ <list entry instance name>.]
786 The <list entry instance name> is only included if the <Function> is a list-based Function. An example
787 could be:
788 DeviceConfiguration. deviceConfigurationKeyValueDescriptionListData.

789 deviceConfigurationKeyValueDescriptionData.
790 In the following rows, only the names of the Elements are stated, without the prefix described above.
791
792 Within the "Server data - Resources" sections each Feature Type is described in an own sub-section
793 with the name "Feature Type "<name of the Feature Type>"" (e.g. "Feature Type "Measurement"").
794 It contains sub-sections for each Function named "Function "<name of the Function>"" (e.g.
795 "Function "measurementListData""). These sections contain one table with all Elements needed for
796 this resource. The list entries are mentioned in a continuous row, highlighted with grey background
797 colour. This row contains the following parts:
798 <Feature Type>. <Function>.[ <list entry instance name>.]
799 The <list entry instance name> is only included if the <Function> is a list-based Function. An example
800 could be:
801 Measurement. measurementDescriptionListData. measurementDescriptionData.
802 In the following rows, only the names of the Elements are stated, without the prefix described above.
803
804 For both kinds of tables, the following applies:
805 - Parent Elements are marked with a dot at the end of the name:
806 <parent Element>.
807 E.g.:
808 value.
809 - If there are sub-Elements, they are described in own rows with the name of the parent
810 Element as prefix, separated by a dot and a blank space:

811 <parent Element>. <sub-Element>

812 E.g.:
813 value. number
814
815 3.1.4 Rules for "Feature Types and Functions..." tables
816 3.1.4.1 Presence indications for "Feature Types and Functions..." tables
817 The following presence indications are used:
Abbreviation Meaning Link to requirement keywords

M Mandatory SHALL
R Recommended SHOULD
O Optional MAY
818 Table 14: Presence indication of Feature Types and Functions support
819 If at least one Function of a Feature has the presence indication "M", it is mandatory to support the
820 Feature.
821
822 3.1.4.2 Rules for "Possible operations" column

823 Within the "Feature Types and Functions..." tables the column "Possible operations" state whether
824 the Function is read- or writeable (as defined in the detailed discovery mechanism, see
825 [ProtocolSpecification]).
826 If the "partial" concept (also called "restricted function exchange") SHALL be supported, the
827 following notation is used (separated for read and write access):
828 read (M). partial (M)

829 write (M). partial (M)
830 If the "partial" concept SHOULD be supported, the following notation is used:
831 read (M). partial (R)

832 write (M). partial (R)
833 If the "partial" concept MAY be supported, the following notation is used:
834 read (M). partial (O)

835 write (M). partial (O)
836 The server can decide whether a notification is submitted complete or partial (as described in
837 [ProtocolSpecification]) if not defined differently within this Use Case Specification.
838
839 3.1.5 "Actor ... overview" diagram rules

840 Within the "Actor [...] overview" diagrams in the "Actors" sub-sections the complete functionality of
841 this Use Case is provided, including optional Scenarios. Which Scenarios are optional can be found in
842 Table 1. The Actor MAY have more functionality implemented than needed for this Use Case.

843 For the following Actor overview example, a brief description of the graphical symbols will be
844 described.
845
846 Figure 4: Actor overview example
847 The solid lines in the figure represent an immediate parent-childhood relation: The Entity with
848 "<Entity Type A>" is a direct child of "Device". The Entity with "<Entity Type D>" is a direct child of the
849 Entity with "<Entity Type B>". All Features are immediate child of the respective Entity.
850 The dashed lines in the figure express that there MAY be additional Entities between the shown
851 Entities: A vendor's implementation MAY have one or more Entities between "Device" and the Entity
852 with "<Entity Type B>". Likewise, a vendor's implementation MAY have one or more Entities between
853 the Entity with "<Entity Type B>" and the Entity with "<Entity Type C>".
854
855 3.1.6 Specializations

856 Within the "Actors" sub-sections, Specializations are referenced. A Specialization describes a dataset
857 necessary to fulfil the specific requirements of a High-Level Use Case and its Scenarios. Often, data
858 from multiple different Features and Functions are needed to fulfil the requirements. Therefore, a
859 Specialization defines a dataset that may encompass multiple related Functions from one or more
860 different Features.
861 As different Use Cases sometimes share similar requirements, Specializations are also important
862 from a re-usability perspective. This approach is used to improve consistency across Use Cases and
863 avoid multiple variances of basically the same dataset. This is especially important in the case when
864 an implementation supports multiple Use Cases. E.g. if a power measurement is necessary in two
865 different Use Cases, both Use Cases could define slightly different datasets. In this case, the server as

866 well as the client functionality would have to implement both variances if both Use Cases are
867 supported. This means, depending on the number of Use Cases, two or more datasets need to be
868 generated, transmitted and stored instead of one. Therefore, common Specializations are defined to
869 enable consolidated implementations. Specializations are detailed per Actor, as distinct Actors may
870 use different parts of a Specialization or even have different permissions to change data. In general,
871 this may also depend on the respective Scenario.
872 If a Feature server can provide the data of a Specialization, the data does not necessarily always need
873 to be available at the Feature server. There might be situations where the user deactivates a Use
874 Case. There may also be other reasons why Use Case data cannot be provided currently. Therefore, a
875 client always needs to be subscribed (as described in section 3.3.4) on the corresponding dataset to
876 stay updated.
877 The SPINE resource descriptions given in the "SPINE resources of the Actor" sections are derived
878 from the Specializations given in the Actor's overview diagram.
879
880 3.1.7 Order of messages within the sequence diagrams

881 There are several sequence diagrams in this document describing message flows. The order of the
882 messages SHOULD be kept by the communications partners, but there might be cases where a
883 different order makes sense. The communications partners SHALL be able to handle the Scenario
884 functionalities even if the messages are transmitted in a different order by the other Actor(s). The
885 sequence diagrams can be seen as examples.
886
887 3.1.8 Further information and rules
888 3.1.8.1 Frequently used Element rules for the Resource and Specialization tables
889 This section serves as a collection of rules frequently used by Resource and Specialization tables of
890 the subsequent sections. Each rule applies only where referenced explicitly in the tables.
891 Note: The purpose of this collection is just to reduce the size of the tables. As such, no rule has a
892 meaning without a reference indicating the required rule. A reference looks like "See [Measurement
893 value rules]", e.g.
894
895 [Measurement value rules]:
896 SHALL be set if a value is available. Otherwise, the whole list entry SHALL be omitted or the Element
897 valueState SHALL be set to "error".
898 If valueState is set to "error", but value is set, the content of value SHALL be ignored by the client.
899 If valueState is set to "outOfRange", but value is set, the content of value SHALL be interpreted as
900 being out of range.
901 If valueState is set to "outOfRange", measurementConstraintsListData. valueRangeMax is set and

902 value is equal or bigger than valueRangeMax, value SHALL be interpreted as above valueRangeMax.

903 If valueState is set to "outOfRange", measurementConstraintsListData. valueRangeMin is set and

904 value is equal or smaller than valueRangeMin, value SHALL be interpreted as below valueRangeMin.
905 If set, measurementDescriptionListData. measurementType SHALL be set, too.
906
907 [Value state rules]:
908 The Element valueState SHALL be set if its content differs from "normal" ([MOB-005]). This means, if
909 the state of the value is "outOfRange" or "error" this SHALL be denoted in the valueState Element. A
910 client SHALL always consider the content of valueState, if set. If omitted, a value of "normal" is
911 assumed.
912
913 [String-length rules]:
914 The string-length SHOULD NOT be longer than 256 characters. If it is longer, the sender SHALL
915 consider the possibility that the receiver will shorten the string to 256 characters.
916
917 [Scaled number rules]:
918 The sub-Elements "number" and "scale" represent a value according to the following formula:
919 number * 10scale
920
921 [Evaluation period rules]:
922 The "evaluationPeriod" expresses the analysis period for the according value.
923
924 3.1.8.2 Rules regarding the usage of time-related information

925 All time-related information within this Use Case SHALL be presented as absolute times. This means
926 relative times SHALL NOT be used, unless the data point only supports relative times (e.g. for a
927 "duration").
928 Note: This means the Actors need to have a common understanding of these absolute times. It is
929 strongly recommended that each Actor is "sufficiently synchronised" with the official "Coordinated
930 Universal Time" (UTC).
931
932 3.1.8.3 Applied sign convention

933 For the applied sign convention, please see section 2.6.1.
934

935 3.2 Actors
936 3.2.1 Monitoring Appliance
937 3.2.1.1 Resource hierarchy

938 If Use Case discovery is supported (see section 3.1.2) this Actor SHALL be denoted as
939 "MonitoringAppliance" in the Element "nodeManagementUseCaseData. useCaseInformation. actor".
940 The following diagram provides an overview of the Actor Monitoring Appliance's resource hierarchy.
941
942 Figure 5: Actor "Monitoring Appliance" overview
943 The ""Actor ... overview" diagram rules" section describes how to interpret the diagram above. See
944 the "Specializations" section for more information regarding the Specializations given in the diagram
945 above.
946 Note: The entityType "DeviceInformation" with the featureType "NodeManagement" is required by
947 the SPINE protocol and therefore SHALL be supported. Both types are added in the figure for
948 completeness but are not directly linked to the Use Case.
949 The Use Case specific data follows behind any entityType. The Specializations represent the Scenario
950 specific data that must be supported for each Scenario and are realized through the corresponding
951 featureTypes.

952 If a Specialization is connected to a Feature with the role "client", the Actor has a client role for this
953 data. This means that the Actor accesses the data set described by the Specialization at a
954 corresponding server Feature. Further details are described in the sub-section "Client data -
955 Specializations".
956 If a Specialization is connected to a Feature with the role "server", the Actor has the server role for
957 this data. This means that the Actor must provide the corresponding data set of the Specialization as
958 part of its Features. Further details are described in the sub-section "Server data - Resources".
Specialization name Scenario Described in

table
DeviceClassification_ManufacturerData_MOB 1 Table 16
DeviceDiagnosis_OperatingState 2 Table 17
Measurement_StateOfCharge 2 Table 18
Measurement_StateOfHealth 2 Table 19
Measurement_StateOfEnergy 2 Table 20
Measurement_UseableCapacity 2 Table 21
Measurement_DcPower 3 Table 22
Measurement_DcCurrent 4 Table 23
Measurement_DcVoltage 5 Table 24
Measurement_DcChargeEnergy 6 Table 25
Measurement_DcDischargeEnergy 6 Table 26
Measurement_LoadCycleCount 7 Table 27
Measurement_ComponentTemperature 9 Table 28
DeviceConfiguration_BatteryType 7 Table 29
DeviceConfiguration_MaxCycleCountPerDay 8 Table 30
ElectricalConnection_EntityEnergyCapacityNominalMax 8 Table 31
ElectricalConnection_EntityPowerConsumptionNominalMax 8 Table 32
ElectricalConnection_EntityPowerProductionNominalMax 8 Table 33
959 Table 15: Specialization support for Actor Monitoring Appliance
960
961 3.2.1.2 Server data - Resources

962 As this Actor has only client functionality, no resources are described within this section.
963
964 3.2.1.3 Client data - Specializations
965 3.2.1.3.1 Topic "DeviceClassification"
966 3.2.1.3.1.1 Specialization "DeviceClassification_ManufacturerData_MOB"

M/R/O [\W][\C]
Scenario [{...}]:
Element and
[High-Level
value rules
Mapping]
Element
Value
1: M DeviceClassification. deviceClassificationManufacturerData.
1: R deviceName [MOB-011]

[String-length rules]
1: R deviceCode [MOB-012]
1: R serialNumber [MOB-013]
1: R softwareRevision [MOB-014]
1: R hardwareRevision [MOB-015]
1: M vendorName [MOB-016]
1: O vendorCode [String-length rules]
1: O brandName [String-length rules]
1: O manufacturerLabel [MOB-017]
1: O manufacturerDescription The string-length SHOULD NOT
be longer than 4096 characters.
967 Table 16: Content of Specialization "DeviceClassification_ManufacturerData_MOB" at Actor Monitoring Appliance
968
969 3.2.1.3.2 Topic "DeviceDiagnosis"
970 3.2.1.3.2.1 Specialization "DeviceDiagnosis_OperatingState"

M/R/O [\W][\C]
Scenario [{...}]:
Element and
[High-Level
value rules
Mapping]
Element
Value
2: M DeviceDiagnosis. deviceDiagnosisStateData.
2: O timestamp
2: M operatingState "normalOperation" [MOB-025/1] [MOB-025]
"standby" [MOB-025/2]
"failure" [MOB-025/5]
"temporarilyNotReady" [MOB-025/3]
"off" [MOB-025/4]
2: O vendorStateCode The string-length SHOULD
NOT be longer than 128
characters.
971 Table 17: Content of Specialization "DeviceDiagnosis_OperatingState" at Actor Monitoring Appliance
972

973 3.2.1.3.3 Topic "Measurement"
974 3.2.1.3.3.1 Specialization "Measurement_StateOfCharge"

M/R/O [\W][\C]
Scenario [{...}]:
Element and
[High-Level
value rules
Mapping]
Element
Value
2: M Measurement. measurementDescriptionListData. measurementDescriptionData.
2: M measurementId <m1#(1..1)> SHALL be set as PRIMARY
IDENTIFIER.
2: M measurementType "percentage"
2: M commodityType "electricity"
2: M unit "pct"
2: M scopeType "stateOfCharge"
2: R Measurement. measurementConstraintsListData. measurementConstraintsData.
IDENTIFIER.
2: R valueRangeMin. [MOB-002/2]
SHOULD be used.
[Scaled number rules]
2: M valueRangeMin. SHALL be used.
number
2: M valueRangeMin. scale SHALL be interpreted. If absent, a
default value of "0" applies.
2: R valueRangeMax. [MOB-002/2]
SHOULD be used.
2: M valueRangeMax. SHALL be used.
number
2: M valueRangeMax. scale SHALL be interpreted. If absent, a
2: R valueStepSize. SHOULD be used.
2: M valueStepSize. number SHALL be used.
2: M valueStepSize. scale SHALL be interpreted. If absent, a
2: M Measurement. measurementListData. measurementData.
IDENTIFIER.
2: M valueType "value" SHALL be set as SUB IDENTIFIER.
2: O timestamp <t#(1..1)->m1#1> MAY be used. Only the newest
measurement value SHALL be
stated. Additional historical values
are forbidden.
2: M value. [MOB-002/2], [MOB-021]
[Measurement value rules]
2: M value. number SHALL be used.

2: M value. scale SHALL be interpreted. If absent, a

2: R valueSource "calculatedValue"
2: M valueState [MOB-005]
[Value state rules]
975 Table 18: Content of Specialization "Measurement_StateOfCharge" at Actor Monitoring Appliance
976
977 3.2.1.3.3.2 Specialization "Measurement_StateOfHealth"

M/R/O [\W][\C]
Scenario [{...}]:
Element and
[High-Level
value rules
Mapping]
Element
Value

2: M measurementId <m2#(1..1)> SHALL be set as PRIMARY IDENTIFIER.
2: M unit "pct"
2: M scopeType "stateOfHealth"
SHOULD be used.
number
SHOULD be used.
number
2: M valueRangeMax. SHALL be interpreted. If absent, a
scale default value of "0" applies.
2: M valueStepSize. SHALL be used.
number
measurement value SHALL be stated.
Additional historical values are
forbidden.
2: M value. [MOB-002/2], [MOB-022]


2: R valueSource "measuredValue"
"calculatedValue"
"empiricalValue"
[Value state rules]
978 Table 19: Content of Specialization "Measurement_StateOfHealth" at Actor Monitoring Appliance
979
980 3.2.1.3.3.3 Specialization "Measurement_StateOfEnergy"

M/R/O [\W][\C]
Scenario [{...}]:
Element and
[High-Level
value rules
Mapping]
Element
Value

2: M measurementType "energy"
2: M unit "Wh"
2: M scopeType "stateOfEnergy"
SHOULD be used.
number
2: M valueRangeMin. scale SHALL be interpreted. If absent, a default
value of "0" applies.
SHOULD be used.
number
2: M valueRangeMax. scale SHALL be interpreted. If absent, a default
2: M valueStepSize. SHALL be used.
number
2: M valueStepSize. scale SHALL be interpreted. If absent, a default


Additional historical values are forbidden.
2: M value. [MOB-002/3], [MOB-023]
2: M value. scale SHALL be interpreted. If absent, a default
"calculatedValue"
"empiricalValue"
[Value state rules]
981 Table 20: Content of Specialization "Measurement_StateOfEnergy" at Actor Monitoring Appliance
982
983 3.2.1.3.3.4 Specialization "Measurement_UseableCapacity"

M/R/O [\W][\C]
Scenario [{...}]:
Element and
[High-Level
value rules
Mapping]
Element
Value

IDENTIFIER.
2: M measurementType "capacity"
2: M unit "Wh"
2: M scopeType "useableCapacity"
IDENTIFIER.
SHOULD be used.
2: M valueRangeMin. number SHALL be used.
SHOULD be used.
2: M valueRangeMax. number SHALL be used.


IDENTIFIER.
are forbidden.
2: M value. [MOB-002/3], [MOB-024]
"calculatedValue"
"empiricalValue"
[Value state rules]
2: M ElectricalConnection. electricalConnectionDescriptionListData.
electricalConnectionDescriptionData.
2: M electricalConnectionId <ec1#(1..1)> SHALL be set as PRIMARY
IDENTIFIER.
2: M powerSupplyType "dc"
2: M positiveEnergyDirection "consume"
2: M ElectricalConnection. electricalConnectionParameterDescriptionListData.
electricalConnectionParameterDescriptionData.
IDENTIFIER.
2: M parameterId <p1#(1..1)->ec1#1> SHALL be set as SUB IDENTIFIER.
2: M measurementId <m4#(1..1)->p1#1> SHALL be set as FOREIGN
IDENTIFIER.
984 Table 21: Content of Specialization "Measurement_UseableCapacity" at Actor Monitoring Appliance
985
986 3.2.1.3.3.5 Specialization "Measurement_DcPower"

M/R/O [\W][\C]
Scenario [{...}]:
Element and
[High-Level
value rules
Mapping]
Element
Value

IDENTIFIER.
3: M measurementType "power"
3: M unit "W"

3: M scopeType "dcPower"
IDENTIFIER.
3: R valueRangeMin. [MOB-001]
SHOULD be used.
3: R valueRangeMax. [MOB-001]
SHOULD be used.
IDENTIFIER.
are forbidden.
3: M value. [MOB-001], [MOB-031]
"calculatedValue"
"empiricalValue"
[Value state rules]
IDENTIFIER.
IDENTIFIER.


IDENTIFIER.
3: M voltageType "dc"
987 Table 22: Content of Specialization "Measurement_DcPower" at Actor Monitoring Appliance
988
989 3.2.1.3.3.6 Specialization "Measurement_DcCurrent"

M/R/O [\W][\C]
Scenario [{...}]:
Element and
[High-Level
value rules
Mapping]
Element
Value
4: M measurementType "current"
4: M unit "A"
4: M scopeType "dcCurrent"
SHOULD be used.
SHOULD be used.
forbidden.
4: M value. [MOB-001], [MOB-041]


"calculatedValue"
"empiricalValue"
[Value state rules]
4: M electricalConnectionId <ec1#(1..1)> SHALL be set as PRIMARY IDENTIFIER.
4: M measurementId <m6#(1..1)->p3#1> SHALL be set as FOREIGN IDENTIFIER.
990 Table 23: Content of Specialization "Measurement_DcCurrent" at Actor Monitoring Appliance
991
992 3.2.1.3.3.7 Specialization "Measurement_DcVoltage"

M/R/O [\W][\C]
Scenario [{...}]:
Element and
[High-Level
value rules
Mapping]
Element
Value

5: M measurementType "voltage"
5: M unit "V"
5: M scopeType "dcVoltage"
SHOULD be used.
SHOULD be used.


forbidden.
5: M value. [MOB-002/1], [MOB-051]
"calculatedValue"
"empiricalValue"
[Value state rules]
993 Table 24: Content of Specialization "Measurement_DcVoltage" at Actor Monitoring Appliance
994
995 3.2.1.3.3.8 Specialization "Measurement_DcChargeEnergy"

M/R/O [\W][\C]
Scenario [{...}]:
Element and
[High-Level
value rules
Mapping]
Element
Value

6: M unit "Wh"
6: M scopeType "dcChargeEnergy"

SHOULD be used.
number
6: M valueRangeMin. scale SHALL be interpreted. If absent, a default
SHOULD be used.
number
6: M valueRangeMax. scale SHALL be interpreted. If absent, a default
6: M valueStepSize. scale SHALL be interpreted. If absent, a default
6: M value. [MOB-001], [MOB-061]
6: M value. scale SHALL be interpreted. If absent, a default
6: O evaluationPeriod. [Evaluation period rules]
6: M evaluationPeriod.
startTime
endTime
"calculatedValue"
"empiricalValue"
[Value state rules]

996 Table 25: Content of Specialization "Measurement_DcChargeEnergy" at Actor Monitoring Appliance
997
998 3.2.1.3.3.9 Specialization "Measurement_DcDischargeEnergy"

M/R/O [\W][\C]
Scenario [{...}]:
Element and
[High-Level
value rules
Mapping]
Element
Value
IDENTIFIER.
6: M unit "Wh"
6: M scopeType "dcDischargeEnergy"
IDENTIFIER.
SHOULD be used.
SHOULD be used.
IDENTIFIER.
are forbidden.
6: M value. [MOB-001], [MOB-062]


startTime
6: M evaluationPeriod. endTime
"calculatedValue"
"empiricalValue"
[Value state rules]
IDENTIFIER.
IDENTIFIER.
IDENTIFIER.
999 Table 26: Content of Specialization "Measurement_DcDischargeEnergy" at Actor Monitoring Appliance
1000
1001 3.2.1.3.3.10 Specialization "Measurement_LoadCycleCount"

M/R/O [\W][\C]
Scenario [{...}]:
Element and
[High-Level
value rules
Mapping]
Element
Value

7: M measurementType "count"
7: M unit "1"
7: M scopeType "loadCycleCount"
7: R valueRangeMin. SHOULD be used.
7: M valueRangeMin. ≥0 SHALL be used. The value of Element
number "number" SHALL be greater than or equal
to zero.
7: M valueRangeMin. ≥0 SHALL be interpreted. If absent, a default
scale value of "0" applies. If present, the value of

Element "scale" SHALL be greater than or

equal to zero.
7: R valueRangeMax. SHOULD be used.
7: M valueRangeMax. ≥0 SHALL be used. The value of Element
to zero.
7: M valueRangeMax. ≥0 SHALL be interpreted. If absent, a default
equal to zero.
7: M valueStepSize. ≥0 SHALL be used. The value of Element
to zero.
7: M valueStepSize. ≥0 SHALL be interpreted. If absent, a default
equal to zero.
7: M value. [MOB-071]
7: M value. number ≥0 SHALL be used. The value of Element
"number" SHALL be greater than or equal
to zero.
7: M value. scale ≥0 SHALL be interpreted. If absent, a default
value of "0" applies. If present, the value of
equal to zero.
"calculatedValue"
"empiricalValue"
[Value state rules]
1002 Table 27: Content of Specialization "Measurement_LoadCycleCount" at Actor Monitoring Appliance
1003
1004 3.2.1.3.3.11 Specialization "Measurement_ComponentTemperature"

M/R/O [\W][\C]
Scenario [{...}]:
Element and
[High-Level
value rules
Mapping]
Element
Value


IDENTIFIER.
9: M measurementType "temperature"
9: M unit "degC" | "degF" | "K"
9: M scopeType "componentTemperature"
IDENTIFIER.
number
number
IDENTIFIER.
are forbidden.
"calculatedValue"
"empiricalValue"
[Value state rules]
1005 Table 28: Content of Specialization "Measurement_ComponentTemperature" at Actor Monitoring Appliance
1006

1007 3.2.1.3.4 Topic "DeviceConfiguration"
1008 3.2.1.3.4.1 Specialization "DeviceConfiguration_BatteryType"

M/R/O [\W][\C]
Scenario [{...}]:
Element and
[High-Level
value rules
Mapping]
Element
7: M Value
DeviceConfiguration. deviceConfigurationKeyValueDescriptionListData.
deviceConfigurationKeyValueDescriptionData.
7: M keyId <k1#(1..1)> SHALL be set as PRIMARY IDENTIFIER.
7: M keyName "batteryType"
7: M valueType "string"
7: M DeviceConfiguration. deviceConfigurationKeyValueListData.
deviceConfigurationKeyValueData.
Exactly one of the child Elements
SHALL be set. This SHALL match with
the content of valueType Element
within the key value description part
(see above).
7: M value. string "liIon" [MOB-072/1]
"leadAcid" [MOB-072/2]
"redoxFlow" [MOB-072/3]
"sodiumIon" [MOB-072/4]
1009 Table 29: Content of Specialization "DeviceConfiguration_BatteryType" at Actor Monitoring Appliance
1010
1011 3.2.1.3.4.2 Specialization "DeviceConfiguration_MaxCycleCountPerDay"

M/R/O [\W][\C]
Scenario [{...}]:
Element and
[High-Level
value rules
Mapping]
Element
Value
8: M DeviceConfiguration. deviceConfigurationKeyValueDescriptionListData.
8: M keyName "maxCycleCountPerDay"
8: M valueType "scaledNumber"
8: M unit "1" The unit SHALL be applied to the value of the
key.
Exactly one of the child Elements SHALL be
set. This SHALL match with the content of

valueType Element within the key value

description part (see above).
8: M value. SHALL be used.
scaledNumber. [Scaled number rules]
8: M value. ≥0 SHALL be used. The value of Element
scaledNumber. "number" SHALL be greater than or equal to
number zero.
8: M value. ≥0 SHALL be interpreted. If absent, a default
scaledNumber. value of "0" applies. If present, the value of
scale Element "scale" SHALL be greater than or
equal to zero.
1012 Table 30: Content of Specialization "DeviceConfiguration_MaxCycleCountPerDay" at Actor Monitoring Appliance
1013
1014 3.2.1.3.5 Topic "ElectricalConnection"
1015 3.2.1.3.5.1 Specialization "ElectricalConnection_EntityEnergyCapacityNominalMax"

M/R/O [\W][\C]
Scenario [{...}]:
Element and
[High-Level
value rules
Mapping]
Element
Value
8: M ElectricalConnection. electricalConnectionCharacteristicListData.
electricalConnectionCharacteristicData.
IDENTIFIER.
8: M parameterId <p1#(1..1)->ec1#1> SHALL be set as SUB
IDENTIFIER.
8: M characteristicId <cc1#(1..1)->p1#1> SHALL be set as SUB
IDENTIFIER.
8: M characteristicContext "entity"
8: M characteristicType "energyCapacityNominalMax"
8: M value. [MOB-002/3], [MOB-081]
8: M value. scale SHALL be interpreted. If
absent, a default value of "0"
applies.
8: M unit "Wh"
1016 Table 31: Content of Specialization "ElectricalConnection_EntityEnergyCapacityNominalMax" at Actor Monitoring Appliance
1017

1018 3.2.1.3.5.2 Specialization "ElectricalConnection_EntityPowerConsumptionNominalMax"

M/R/O [\W][\C]
Scenario [{...}]:
Element and
[High-Level
value rules
Mapping]
Element
Value
IDENTIFIER.
IDENTIFIER.
IDENTIFIER.
8: M characteristicType "powerConsumptionNominalMax"
8: M value. [MOB-003], [MOB-082]
absent, a default value of
"0" applies.
8: M unit "W"
1019 Table 32: Content of Specialization "ElectricalConnection_EntityPowerConsumptionNominalMax" at Actor Monitoring
1020 Appliance
1021
1022 3.2.1.3.5.3 Specialization "ElectricalConnection_EntityPowerProductionNominalMax"

M/R/O [\W][\C]
Scenario [{...}]:
Element and
[High-Level
value rules
Mapping]
Element
Value
IDENTIFIER.
IDENTIFIER.
IDENTIFIER.
8: M characteristicType "powerProductionNominalMax"
8: M value. [MOB-003], [MOB-083]


absent, a default value of "0"
applies.
8: M unit "W"
1023 Table 33: Content of Specialization "ElectricalConnection_EntityPowerProductionNominalMax" at Actor Monitoring
1024 Appliance
1025
1026 3.2.2 Battery
1027 3.2.2.1 Resource hierarchy

1028 If Use Case discovery is supported (see section 3.1.2) this Actor SHALL be denoted as "Battery" in the
1029 Element "nodeManagementUseCaseData. useCaseInformation. actor".
1030 The following diagram provides an overview of the Actor Battery's resource hierarchy.
1031
1032 Figure 6: Actor "Battery" overview

1033 The ""Actor ... overview" diagram rules" section describes how to interpret the diagram above. See
1034 the "Specializations" section for more information regarding the Specializations given in the diagram
1035 above.
1036 Note: The entityType "DeviceInformation" with the featureType "NodeManagement" is required by
1037 the SPINE protocol and therefore SHALL be supported. Both types are added in the figure for
1038 completeness but are not directly linked to the Use Case.
1039 The Use Case specific data follows behind the entityType "Battery", which is a sub-Entity of the Entity
1040 "Inverter" that is a sub-Entity of one of the following Entities: "PVESHybrid" ([MOB-004/1]) or
1041 "ElectricalStorage" ([MOB-004/2]) (see section 2.2). The Specializations represent the Scenario
1042 specific data that must be supported for each Scenario and are realized through the corresponding
1043 featureTypes.
1044 Note: As shown in Figure 2, an Inverter may have more than one Battery attached. This means the
1045 Entity "Inverter" in Figure 6 may contain more than one Entity with entityType "Battery". In this Use
1046 Case, each "Battery" Entity represents exactly one individual Actor Battery.
1047 If a Specialization is connected to a Feature with the role "client", the Actor has a client role for this
1048 data. This means that the Actor accesses the data set described by the Specialization at a
1049 corresponding server Feature. Further details are described in the sub-section "Client data -
1050 Specializations".
1051 If a Specialization is connected to a Feature with the role "server", the Actor has the server role for
1052 this data. This means that the Actor must provide the corresponding data set of the Specialization as
1053 part of its Features. Further details are described in the sub-section "Server data - Resources".
Specialization name Scenario Used Feature... ...in

tables
DeviceClassification_ManufacturerData_MOB 1 DeviceClassification Table 36
DeviceDiagnosis_OperatingState 2 DeviceDiagnosis Table 39
Measurement_StateOfCharge 2 Measurement Table 43
Measurement_StateOfHealth 2 Table 44
Measurement_StateOfEnergy 2 Table 45
Measurement_UseableCapacity 2 ElectricalConnection Table 40
Measurement_DcPower 3 Table 41
Measurement_DcCurrent 4 Measurement Table 43
Measurement_DcVoltage 5 Table 44
Measurement_DcChargeEnergy 6 Table 45
Measurement_DcDischargeEnergy 6
Measurement_LoadCycleCount 7 Measurement Table 43
Measurement_ComponentTemperature 9 Table 44
Table 45
DeviceConfiguration_BatteryType 7 DeviceConfiguration Table 37
DeviceConfiguration_MaxCycleCountPerDay 8 Table 38
ElectricalConnection_EntityEnergyCapacityNomin 8 ElectricalConnection Table 42
alMax
ElectricalConnection_EntityPowerConsumptionN 8
ominalMax

ElectricalConnection_EntityPowerProductionNom 8
inalMax
1054 Table 34: Specialization support for Actor Battery
1055
1056 3.2.2.2 Server data - Resources
1057 3.2.2.2.1 Overview

1058 Behind the entityType "Battery", the Actor Battery SHALL offer the Feature Types and Functions
1059 given in the table below.
Feature Type Scenario: Function Possible

M/R/O operations
DeviceClassification 1: M deviceClassificationManufacturerData read (M)
DeviceConfiguration 7: M deviceConfigurationKeyValueDescriptionListData read (M).
8: M partial (R)
7: M deviceConfigurationKeyValueListData read (M).
8: M partial (R)
DeviceDiagnosis 2: M deviceDiagnosisStateData read (M)
ElectricalConnection 2: M electricalConnectionDescriptionListData read (M).
3: M partial (R)
4: M
5: M
6: M
2: M electricalConnectionParameterDescriptionListData read (M).
3: M partial (R)
4: M
5: M
6: M
8: M electricalConnectionCharacteristicListData read (M).
partial (R)
Measurement 2: M measurementDescriptionListData read (M).
3: M partial (R)
4: M
5: M
6: M
7: M
9: M
2: R measurementConstraintsListData read (M).
3: R partial (R)
4: R
5: R
6: R
7: R
9: R
2: M measurementListData read (M).
3: M partial (R)
4: M
5: M
6: M
7: M
9: M

1060 Table 35: Feature Types and Functions used within this Use Case by the Actor Battery
1061 For each of these Feature Types, the following rule applies: There SHALL be at maximum one Feature
1062 with the Feature Type in the Entity.
1063 Note: As a consequence of the previous rule, an implementation may need to have Feature data
1064 from different Scenarios/Specializations or even Use Cases in a given Feature.
1065 The Scenario number shows in which Scenarios the Battery acts as server and which Feature Types
1066 and Functions are relevant in each Scenario.
1067 A detailed definition of the Elements and values that shall be supported in each Function is given in
1068 the following sub-sections.
1069 Note: If in the table above "partial" read is not mentioned or is only optional, it still might be
1070 mandatory to support partial notifications. The details of "partial" support are described within the
1071 Scenario sections.
1072 Note: The presence indications stated above are meant relative to the ones of the according Scenario
1073 stated in Table 1. I.e., if a Scenario is optional ("O") and a Feature Type is mandatory ("M"), the
1074 Feature Type need only be supported if the Scenario is supported, too.
1075 Note: Further Features MAY be implemented on the same Entities; also, further Functions MAY be
1076 implemented in the used Entities.
1077
1078 3.2.2.2.2 Feature Type "DeviceClassification"
1079 3.2.2.2.2.1 Function "deviceClassificationManufacturerData"

M/R/O [\W][\C]
Scenario [{...}]:
Element and
[High-Level
value rules
Mapping]
Element
Value
1: M DeviceClassification. deviceClassificationManufacturerData.
1: R deviceName [MOB-011]
1: R deviceCode [MOB-012]
1: R serialNumber [MOB-013]
1: R softwareRevision [MOB-014]
1: R hardwareRevision [MOB-015]
1: M vendorName [MOB-016]
1: O vendorCode [String-length rules]
1: O brandName [String-length rules]

1: O manufacturerLabel [MOB-017]
1: O manufacturerDescription The string-length SHOULD NOT
be longer than 4096 characters.
1080 Table 36: Content of Function "deviceClassificationManufacturerData" at Actor Battery
1081
1082 3.2.2.2.3 Feature Type "DeviceConfiguration"
1083 3.2.2.2.3.1 Function "deviceConfigurationKeyValueDescriptionListData"

M/R/O [\W][\C]
Scenario [{...}]:
Element and
[High-Level
value rules
Mapping]
Element
Value
7: M keyName "batteryType"
7: M valueType "string"
8: M keyName "maxCycleCountPerDay"
8: M valueType "scaledNumber"
8: M unit "1" The unit SHALL be applied to the value of
the key.
1084 Table 37: Content of Function "deviceConfigurationKeyValueDescriptionListData" at Actor Battery
1085
1086 3.2.2.2.3.2 Function "deviceConfigurationKeyValueListData"

M/R/O [\W][\C]
Scenario [{...}]:
Element and
[High-Level
value rules
Mapping]
Element
Value
Exactly one of the child Elements SHALL be set. This
SHALL match with the content of valueType Element
within the key value description part (see above).
7: M value. string "liIon" [MOB-072/1]
"leadAcid" [MOB-072/2]
"redoxFlow" [MOB-072/3]
"sodiumIon" [MOB-072/4]

Exactly one of the child Elements SHALL be set. This
SHALL match with the content of valueType Element
within the key value description part (see above).
8: M value. SHALL be used.
scaledNumber. [Scaled number rules]
8: M value. ≥0 SHALL be used. The value of Element "number"
scaledNumber. SHALL be greater than or equal to zero.
number
8: O value. ≥0 MAY be used. If absent, a default value of "0"
scaledNumber. applies. If present, the value of Element "scale"
scale SHALL be greater than or equal to zero.
1087 Table 38: Content of Function "deviceConfigurationKeyValueListData" at Actor Battery
1088
1089 3.2.2.2.4 Feature Type "DeviceDiagnosis"
1090 3.2.2.2.4.1 Function "deviceDiagnosisStateData"

M/R/O [\W][\C]
Scenario [{...}]:
Element and
[High-Level
value rules
Mapping]
Element
Value
2: M DeviceDiagnosis. deviceDiagnosisStateData.
2: O timestamp
2: M operatingState "normalOperation" [MOB-025/1] [MOB-025]
"standby" [MOB-025/2]
"failure" [MOB-025/5]
"temporarilyNotReady" [MOB-025/3]
"off" [MOB-025/4]
2: O vendorStateCode The string-length SHOULD
NOT be longer than 128
characters.
1091 Table 39: Content of Function "deviceDiagnosisStateData" at Actor Battery
1092
1093 3.2.2.2.5 Feature Type "ElectricalConnection"
1094 3.2.2.2.5.1 Function "electricalConnectionDescriptionListData"

M/R/O [\W][\C]
Scenario [{...}]:
Element and
[High-Level
value rules
Mapping]
Element
Value

3: M electricalConnectionDescriptionData.
4: M
5: M
6: M
3: M IDENTIFIER.
4: M
5: M
6: M
3: M
4: M
5: M
6: M
3: M
4: M
5: M
6: M
1095 Table 40: Content of Function "electricalConnectionDescriptionListData" at Actor Battery
1096
1097 3.2.2.2.5.2 Function "electricalConnectionParameterDescriptionListData"

M/R/O [\W][\C]
Scenario [{...}]:
Element and
[High-Level
value rules
Mapping]
Element
Value
IDENTIFIER.
IDENTIFIER.
IDENTIFIER.
IDENTIFIER.
IDENTIFIER.
IDENTIFIER.
IDENTIFIER.


IDENTIFIER.
IDENTIFIER.
IDENTIFIER.
IDENTIFIER.
IDENTIFIER.
IDENTIFIER.
IDENTIFIER.
IDENTIFIER.
IDENTIFIER.
IDENTIFIER.
IDENTIFIER.
1098 Table 41: Content of Function "electricalConnectionParameterDescriptionListData" at Actor Battery
1099
1100 3.2.2.2.5.3 Function "electricalConnectionCharacteristicListData"

M/R/O [\W][\C]
Scenario [{...}]:
Element and
[High-Level
value rules
Mapping]
Element
Value
IDENTIFIER.
IDENTIFIER.
IDENTIFIER.

8: M characteristicType "energyCapacityNominalMax"
8: M value. [MOB-002/3], [MOB-081]
8: O value. scale MAY be used. If absent, a
8: M unit "Wh"
IDENTIFIER.
IDENTIFIER.
IDENTIFIER.
8: M characteristicType "powerConsumptionNominalMax"
8: M value. [MOB-003], [MOB-082]
8: M unit "W"
IDENTIFIER.
IDENTIFIER.
IDENTIFIER.
8: M characteristicType "powerProductionNominalMax"
8: M value. [MOB-003], [MOB-083]
8: M unit "W"
1101 Table 42: Content of Function "electricalConnectionCharacteristicListData" at Actor Battery
1102

1103 3.2.2.2.6 Feature Type "Measurement"
1104 3.2.2.2.6.1 Function "measurementDescriptionListData"

M/R/O [\W][\C]
Scenario [{...}]:
Element and
[High-Level
value rules
Mapping]
Element
Value
2: M unit "pct"
2: M scopeType "stateOfCharge"
2: M unit "pct"
2: M scopeType "stateOfHealth"
2: M unit "Wh"
2: M scopeType "stateOfEnergy"
2: M measurementType "capacity"
2: M unit "Wh"
2: M scopeType "useableCapacity"
3: M measurementType "power"
3: M unit "W"
3: M scopeType "dcPower"
4: M measurementType "current"
4: M unit "A"
4: M scopeType "dcCurrent"
5: M measurementType "voltage"
5: M unit "V"
5: M scopeType "dcVoltage"


6: M unit "Wh"
6: M scopeType "dcChargeEnergy"
6: M unit "Wh"
6: M scopeType "dcDischargeEnergy"
7: M measurementType "count"
7: M unit "1"
7: M scopeType "loadCycleCount"
9: M measurementType "temperature"
9: M unit "degC" | "degF" | "K"
9: M scopeType "componentTemperature"
1105 Table 43: Content of Function "measurementDescriptionListData" at Actor Battery
1106
1107 3.2.2.2.6.2 Function "measurementConstraintsListData"

M/R/O [\W][\C]
Scenario [{...}]:
Element and
[High-Level
value rules
Mapping]
Element
Value

SHOULD be used.
2: O valueRangeMin. scale MAY be used. If absent, a default value of "0"
applies.
SHOULD be used.
2: O valueRangeMax. scale MAY be used. If absent, a default value of "0"
applies.

2: O valueStepSize. scale MAY be used. If absent, a default value of "0"

applies.
SHOULD be used.
applies.
SHOULD be used.
applies.
applies.
SHOULD be used.
applies.
SHOULD be used.
applies.
applies.
SHOULD be used.
applies.
SHOULD be used.


applies.
applies.
SHOULD be used.
applies.
SHOULD be used.
applies.
applies.
SHOULD be used.
applies.
SHOULD be used.
applies.
applies.
SHOULD be used.


applies.
SHOULD be used.
applies.
applies.
SHOULD be used.
applies.
SHOULD be used.
applies.
applies.
SHOULD be used.
applies.
SHOULD be used.
applies.
applies.


7: M valueRangeMin. number ≥0 SHALL be used. The value of Element
"number" SHALL be greater than or equal to
zero.
7: O valueRangeMin. scale ≥0 MAY be used. If absent, a default value of "0"
applies. If present, the value of Element
"scale" SHALL be greater than or equal to
zero.
7: M valueRangeMax. number ≥0 SHALL be used. The value of Element
zero.
7: O valueRangeMax. scale ≥0 MAY be used. If absent, a default value of "0"
zero.
7: M valueStepSize. number ≥0 SHALL be used. The value of Element
zero.
7: O valueStepSize. scale ≥0 MAY be used. If absent, a default value of "0"
zero.
applies.
applies.
applies.
1108 Table 44: Content of Function "measurementConstraintsListData" at Actor Battery
1109

1110 3.2.2.2.6.3 Function "measurementListData"

M/R/O [\W][\C]
Scenario [{...}]:
Element and
[High-Level
value rules
Mapping]
Element
Value
IDENTIFIER.
stated. Additional historical
values are forbidden.
2: M value. [MOB-002/2], [MOB-021]
2: M valueSource "calculatedValue"
2: R valueState [MOB-005]
[Value state rules]
IDENTIFIER.
2: M value. [MOB-002/2], [MOB-022]
2: M valueSource "measuredValue"
"calculatedValue"
"empiricalValue"
[Value state rules]
IDENTIFIER.

2: M value. [MOB-002/3], [MOB-023]

"calculatedValue"
"empiricalValue"
[Value state rules]
IDENTIFIER.
2: M value. [MOB-002/3], [MOB-024]
"calculatedValue"
"empiricalValue"
[Value state rules]
IDENTIFIER.
3: M value. [MOB-001], [MOB-031]
"calculatedValue"
"empiricalValue"
[Value state rules]
IDENTIFIER.

4: M value. [MOB-001], [MOB-041]
"calculatedValue"
"empiricalValue"
[Value state rules]
IDENTIFIER.
5: M value. [MOB-002/1], [MOB-051]
"calculatedValue"
"empiricalValue"
[Value state rules]
IDENTIFIER.
6: M value. [MOB-001], [MOB-061]
6: M evaluationPeriod. startTime

"calculatedValue"
"empiricalValue"
[Value state rules]
IDENTIFIER.
6: M value. [MOB-001], [MOB-062]
6: M evaluationPeriod. startTime
"calculatedValue"
"empiricalValue"
[Value state rules]
IDENTIFIER.
7: M value. number ≥0 SHALL be used. The value of
Element "number" SHALL be
greater than or equal to zero.
7: O value. scale ≥0 MAY be used. If absent, a
default value of "0" applies. If
present, the value of Element
"scale" SHALL be greater than or
equal to zero.
"calculatedValue"
"empiricalValue"
[Value state rules]


IDENTIFIER.
"calculatedValue"
"empiricalValue"
[Value state rules]
1111 Table 45: Content of Function "measurementListData" at Actor Battery
1112
1113 3.2.2.3 Client data - Specializations

1114 As this Actor has only server functionality, no Specializations are described within this section.
1115
1116 3.3 Pre-Scenario communication
1117 3.3.1 General information

1118 The Pre-Scenario communication is needed if a client does not know the corresponding addresses on
1119 the server or if the required subscriptions or bindings are not active. In this case certain general
1120 communication mechanisms SHALL be used within SPINE:
1121 a) Detailed discovery: allows to discover resource addresses.

1122 b) Binding: allows to bind to resource address, which is frequently necessary to obtain write
1123 privileges.
1124 c) Subscription: allows to subscribe to resource addresses, which is necessary to receive
1125 unsolicited notifications if a resource changes during runtime.
1126 It is possible to combine those steps for multiple Scenarios or also multiple Use Cases:
1127 - E.g. if multiple Scenarios in multiple Use Cases use the same Feature, only one subscription
1128 needs to occur.
1129 - E.g. a complete detailed discovery or a subscription to the NodeManagement Feature needs
1130 to occur only once for all Use Cases.
1131 Depending on which Entity, Feature and Functions are used within a Scenario the payload of the
1132 corresponding messages may slightly differ, but the basic principles and messages used stay the
1133 same.

1134 The subsequent messages SHALL be exchanged for those parts that have not already been performed
1135 since the current connection is established or if those parts are outdated for another reason (e.g. if
1136 the detailed discovery is needed, but the bindings and subscriptions are still active from a previous
1137 connection only the detailed discovery messages need to be exchanged). If all Pre-Scenario
1138 communication parts are up-to-date, this section MAY be skipped, and the implementation can
1139 proceed as described in the corresponding "Scenario communication" sections.
1140 After the connection is re-established (e.g. due to a power loss or a firmware update) the Pre-
1141 Scenario communication SHALL be performed as well. There may be circumstances where messages
1142 from the Pre-Scenario communication may be exchanged again.
1143 Often the necessary messages of different Scenarios can be combined, so that only one single
1144 message is needed instead of multiple messages for the different Scenarios. This also is the case for
1145 the Pre-Scenario communication. In most cases only one "read" operation on the detailed discovery
1146 is necessary, as well as only one subscription request or binding request is needed for each Feature.
1147 Often multiple Scenarios within a Use Case access the same Feature, so only one subscription or
1148 binding is necessary.
1149
1150 3.3.2 Detailed discovery

1151 For the functionality where a client already has current detailed discovery information (i.e.
1152 independent of this Use Case or any Scenario of it) the remainder of this section SHOULD be skipped.
1153 Otherwise, the following procedure SHALL be performed in the given order:
1154 1. If a client is not subscribed to the primary NodeManagement instance, the client SHALL
1155 acquire a subscription according to the figure provided within this sub-section.
1156 2. A client SHALL read the detailed discovery information according to the figure provided
1157 within this sub-section. It SHALL keep the received information as far as it concerns
1158 mandatory and supported optional Entity Types, Feature Types and Functions of this Use
1159 Case that are needed by the client. This means that a client may choose how to store the
1160 necessary information. E.g. a client Actor can store the information how to address the
1161 necessary Features of the implemented Scenarios but may discard the Entity information.
1162 3. If and as long as a client has a subscription to the detailed discovery information of an Actor
1163 and receives proper notifications, it SHALL consider (i.e. integrate into the kept detailed
1164 discovery information) the received information as far as it concerns mandatory and
1165 supported optional Entity Types, Feature Types and Functions of this Use Case.

1166
1167 Figure 7: Pre-Scenario communication - Detailed discovery sequence diagram
1168 If the "nodeManagementDetailedDiscoveryData read" fails, the client SHOULD retry to read the
1169 detailed discovery information until the "nodeManagementDetailedDiscoveryData reply" message
1170 was received successfully.
1171 If all functionality is present at all times: The "nodeManagementDetailedDiscoveryData reply"

1172 message contains at least the mandatory Entities and Features given in the "Actor [...] overview"
1173 diagrams as well as the used Functions and their "possible operations" described in section 3.2 and
1174 its sub-sections.
1175 If functionality is added or removed dynamically: The "nodeManagementDetailedDiscoveryData

1176 reply" message does not need to contain all mandatory Entities and Features given in the "Actor [...]
1177 overview" diagrams as well as all needed Functions and their "possible operations" described in
1178 section 3.2 and its sub-sections. However, as soon as the functionality is available it will be
1179 announced via a "nodeManagementDetailedDiscoveryData notify" message.
1180 For the nodeManagementDetailedDiscoveryData read Function it is recommended to use a partial

1181 read with separated Selectors that may use one of the following Elements:
1182 - entityType
1183 - featureType

1184 Note: Even with the usage of Selectors Features and Entities that are not relevant for this Use Case
1185 may be discovered. However, only Features and Entities that fulfil the hierarchical order as described
1186 within the Actors' sections shall be considered for this Use Case.
1187 A "partial" notify SHALL be supported without using Selectors and Elements. Partial "delete" notify
1188 SHOULD also be supported with separated Selectors that may use one of the following Elements:
1189 - entityAddress
1190 - featureAddress
1191
1192 3.3.3 Binding

1193 If binding is required by a Scenario that uses Features with writeable or changeable data, the server
1194 SHALL support binding for the respective Features. Before a write on a Function of a Feature occurs,
1195 the client SHALL create a binding to the corresponding Feature. For this the
1196 nodeManagementBindingRequestCall Function is used as shown in the following sequence diagram:
1197
1198 Figure 8: Pre-Scenario communication - Binding sequence diagram
1199 If functionality is added or removed dynamically, binding may not be possible at all times on the
1200 required Functions. A client SHALL retry to create a binding again when receiving according updated
1201 detailed discovery information.
1202
1203 3.3.4 Subscription

1204 A server SHALL support subscription for all Features that contain readable data that may change
1205 during runtime. The client SHALL create a subscription for all Features that the client wants to read.
1206 For this the nodeManagementSubscriptionRequestCall Function is used as shown in the following
1207 sequence diagram:

1208
1209 Figure 9: Pre-Scenario communication - Subscription sequence diagram
1210 If the subscription request fails (e.g. because it is not supported by the server or the maximum
1211 number of possible subscriptions is reached), the client SHOULD read the data periodically (so-called
1212 "polling").
1213 If functionality is added or removed dynamically, subscription may not be possible at all times on the
1214 required Functions. A client SHALL retry its subscription procedure again when receiving according
1215 updated detailed discovery information.
1216
1217 3.3.5 Dynamic behaviour

1218 In case Entities or Features are removed, a nodeManagementDetailedDiscoveryData "notify" is
1219 transmitted that informs about the deleted Entities and Features. All existing binding or subscription
1220 entries on the deleted Features SHALL be deleted by each device.
1221 In case Entities or Features are added the Pre-Scenario communication starts with transmitting a
1222 nodeManagementDetailedDiscoveryData "notify" that contains the added Entities and Features.
1223
1224 3.4 Scenarios
1225 3.4.1 Scenario 1-9 - Overall Scenario information
1226 3.4.1.1 Pre-Scenario communication

1227 1. Detailed Discovery: Actors that act as client within the Scenarios of this Use Case, need to
1228 know the addresses of the server Features used in the Initial Scenario communication. If the
1229 address of a particular server Feature is not known, the detailed discovery must be used, as
1230 described in section 3.3.2.
1231 2. Binding: Binding SHOULD NOT be used for the Scenarios of this Use Case.
1232 3. Subscription: Actors SHALL create a subscription for each server Feature that is relevant for
1233 the corresponding Actor within the Scenarios of this Use Case, as described in section 3.3.4.
1234 The Initial Scenario communication SHALL start at the latest when the required resources on an Actor
1235 are known and the necessary binding and subscription procedures have been finished. However, as

1236 soon as the address of a required resource is known, the Initial Scenario communication for this
1237 resource MAY start already, even if the addresses of other required resources are not known yet.
1238 If required resources are removed and added again, they are re-discovered, and the Initial Scenario
1239 communication is triggered again for those resources.
1240 Note: This section holds for all Scenarios of this Use Case.
1241
1242 3.4.1.2 Initial Scenario communication

1243 Each time a (re-)connection is established, even if the Pre-Scenario communication phase is skipped,
1244 the following messages as shown in the sequence diagram SHALL be exchanged (if a supported
1245 Scenarios requires the respective messsage), as the corresponding resources may have changed in
1246 the meantime:

1247
1248 Figure 10: Scenario 1-9 - Initial Scenario communication sequence diagram

1249
1250 The following table shows where the required content of the messages from the sequence diagram is
1251 described:
Message name from sequence diagram Content Relevant for

description in Scenario
table
deviceClassificationManufacturerData reply Table 36 1
deviceConfigurationKeyValueDescriptionListData reply Table 37 7
8
deviceConfigurationKeyValueListData reply Table 38 7
8
deviceDiagnosisStateData reply Table 39 2
electricalConnectionDescriptionListData reply Table 40 2
3
4
5
6
electricalConnectionParameterDescriptionListData reply Table 41 2
3
4
5
6
electricalConnectionCharacteristicListData reply Table 42 8
measurementDescriptionListData reply Table 43 2
3
4
5
6
7
9
measurementConstraintsListData reply Table 44 2
3
4
5
6
7
9
measurementListData reply Table 45 2
3
4
5
6
7
9
1252 Table 46: Initial Scenario communication content references for Scenario 1-9
1253 Note: Within the Initial Scenario communication, the content required by the Scenarios of this Use
1254 Case MAY not be provided completely, but later during Runtime Scenario communication.

1256
1257 3.4.1.3 Runtime Scenario communication

1258 Based on the Initial Scenario communication, the Runtime Scenario communication provides updates
1259 during runtime.
1260 If one of the referenced server Functions' data change, the server SHALL submit the change as shown
1261 in the following figure:

1262
1263 Figure 11: Scenario 1-9 - Runtime Scenario communication sequence diagram
1264 Note: To interpret partial notification messages correctly, the information obtained during the Initial
1265 Scenario communication phase is required.

1266 Note: A read operation ("polling") on all Functions is possible at any time, e.g. if a notification could
1267 not be evaluated.
1268
1269 The following table shows where the required content of the messages of the sequence diagram is
1270 described:
Message name from sequence diagram Content Relevant for

description in Scenario
table
deviceClassificationManufacturerData notify Table 36 1
deviceConfigurationKeyValueDescriptionListData notify Table 37 7
8
deviceConfigurationKeyValueListData notify Table 38 7
8
deviceDiagnosisStateData notify Table 39 2
electricalConnectionDescriptionListData notify Table 40 2
3
4
5
6
electricalConnectionParameterDescriptionListData notify Table 41 2
3
4
5
6
electricalConnectionCharacteristicListData notify Table 42 8
measurementDescriptionListData notify Table 43 2
3
4
5
6
7
9
measurementConstraintsListData notify Table 44 2
3
4
5
6
7
9
measurementListData notify Table 45 2
3
4
5
6
7
9
1271 Table 47: Runtime Scenario communication content references for Scenario 1-9

1273
1274 3.4.2 Scenario 1 - Monitor Battery identification
1275 3.4.2.1 Additional information

1276 None.
1277
1278 3.4.3 Scenario 2 - Monitor Battery state

1280 None.
1281
1282 3.4.3.2 Information access

1283 Partial data information regarding [MOB-021]:
1284 The measurementDescriptionListData read SHOULD be a "partial" read operation with the following
1285 Selector:
1286 - scopeType = "stateOfCharge"
1287 The measurementConstraintsListData read and measurementListData read SHOULD be "partial" read
1288 operations with the following Selector:
1289 - measurementId (derived from the measurementDescriptionListData reply)
1290 Note: If partial read is not supported, a full read SHALL be performed.
1291
1294 Selector:
1295 - scopeType = "stateOfHealth"
1300
1303 Selector:

1304 - scopeType = "stateOfEnergy"
1309
1312 Selector:
1313 - scopeType = "useableCapacity"
1314 The measurementConstraintsListData read, measurementListData and

1315 electricalConnectionParameterDescriptionListData read SHOULD be "partial" read operations with
1316 the following Selector:
1318 The electricalConnectionDescriptionListData read SHOULD be a "partial" read operation with the
1319 following Selector:
1320 - electricalConnectionId (derived from the electricalConnectionParameterDescriptionListData

1321 reply)
1323
1324 3.4.4 Scenario 3 - Monitor Battery DC power

1326 None.
1327

1331 Selector:
1332 - scopeType = "dcPower"
1333 The measurementConstraintsListData read, measurementListData read and



1340 reply)
1342
1343 3.4.5 Scenario 4 - Monitor Battery DC current

1345 None.
1346

1350 Selector:
1351 - scopeType = "dcCurrent"


1359 reply)
1361
1362 3.4.6 Scenario 5 - Monitor Battery DC voltage

1364 None.
1365


1369 Selector:
1370 - scopeType = "dcVoltage"


1378 reply)
1380
1381 3.4.7 Scenario 6 - Monitor Battery DC energy

1383 None.
1384

1388 Selector:
1389 - scopeType = "dcChargeEnergy"


1397 reply)
1399

1402 Selector:
1403 - scopeType = "dcDischargeEnergy"


1411 reply)
1413
1414 3.4.8 Scenario 7 - Monitor Battery additional details

1416 Note on [MOB-071]: As the Cumulated Load Cycle Count ([MOB-071]) is an integer value, its
1417 numerical representation via the Elements "number" and "scale" is restricted: Both Elements SHALL
1418 be greater than or equal to zero (see Table 45 and also Table 44). This also means that
1419 representations like { number=200, scale=-2 } are forbidden, even though the calculation of
1421 (see [Scaled number rules]) would yield an integer value of "2" in this example.
1422

1426 Selector:
1427 - scopeType = "loadCycleCount"
1432

1434 The deviceConfigurationKeyValueDescriptionListData read SHOULD be a "partial" read operation

1435 with the following Selector:
1436 - keyName = "batteryType"
1437 The deviceConfigurationKeyValueListData read SHOULD be a "partial" read operation with the
1439 - keyId (derived from the deviceConfigurationKeyValueDescriptionListData reply)
1441
1442 3.4.9 Scenario 8 - Monitor Battery capabilities

1444 Note on [MOB-084]: As the Battery Maximum Charge/Discharge Cycle Count Per Day ([MOB-084]) is
1445 an integer value, its numerical representation via the Elements "number" and "scale" is restricted:
1446 Both Elements SHALL be greater than or equal to zero (see Table 38). This also means that
1447 representations like { number=200, scale=-2 } are forbidden, even though the calculation of
1449 (see [Scaled number rules]) would yield an integer value of "2" in this example.
1450
1451

1454 The electricalConnectionCharacteristicListData read SHOULD be a "partial" read operation with the
1456 - electricalConnectionId = <if [MOB-024] is supported by Actor Monitoring Appliance AND

1457 available on Actor Battery, the same value as used within [MOB-024] SHALL be used here;
1458 otherwise, the electricalConnectionId is not needed within the "partial" read operation>
1459 - parameterId = <if [MOB-024] is supported by Actor Monitoring Appliance AND available on
1460 Actor Battery, the same value as used within [MOB-024] SHALL be used here; otherwise, the
1461 parameterId is not needed within the "partial" read operation>
1462 - characteristicContext = "entity"
1463 - characteristicType = "energyCapacityNominalMax"
1465

1469 - electricalConnectionId = <same value as used within [MOB-031]>

1470 - parameterId = <same value as used within [MOB-031]>
1472 - characteristicType = "powerConsumptionNominalMax"
1474
1478 - electricalConnectionId = <same value as used within [MOB-031]>

1479 - parameterId = <same value as used within [MOB-031]>
1481 - characteristicType = "powerProductionNominalMax"
1483
1485 The deviceConfigurationKeyValueDescriptionListData read SHOULD be a "partial" read operation

1486 with the following Selector:
1487 - keyName = "maxCycleCountPerDay"
1488 The deviceConfigurationKeyValueListData read SHOULD be a "partial" read operation with the
1490 - keyId (derived from the deviceConfigurationKeyValueDescriptionListData reply)
1492
1493 3.4.10 Scenario 9 - Monitor Internal data

1495 None.
1496


1500 Selector:
1501 - scopeType = "componentTemperature"
1506

EEBus UC TS MonitoringOfBattery V1.0.0 RC4 Public

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

EEBus UC TS MonitoringOfBattery V1.0.0 RC4 Public

Uploaded by

Copyright:

Available Formats

EEBus Initiative e.V.

The EEBus concept was

Terms of use for publications of EEBus Initiative e.V.

Copyright, rights of use and exploitation

Copyright © 2022 EEBus Initiative e.V. All rights reserved. Page 2 of 92

Copyright © 2022 EEBus Initiative e.V. All rights reserved. Page 3 of 92

47 3.2.2 Battery ........................................................................................................................... 55

Copyright © 2022 EEBus Initiative e.V. All rights reserved. Page 4 of 92

Copyright © 2022 EEBus Initiative e.V. All rights reserved. Page 5 of 92

135 Table 43: Content of Function "measurementDescriptionListData" at Actor Battery.......................... 65

Copyright © 2022 EEBus Initiative e.V. All rights reserved. Page 6 of 92

142 1 Scope of the document

148 1.1 References

149 1.1.1 EEBUS documents

151 [ResourceSpecification] EEBus_SPINE_TS_ResourceSpecification.pdf

152 [SHIP] EEBus_SHIP_TS_Specification_v1.0.1.pdf

154 1.1.2 Normative references

158 1.2 Terms and definitions

163 Active sign convention

Copyright © 2022 EEBus Initiative e.V. All rights reserved. Page 7 of 92

180 Monitoring Appliance

182 Passive sign convention

206 1.3 Requirements

207 1.3.1 Requirements wording

214 Note: They apply only if written in capital letters.

Copyright © 2022 EEBus Initiative e.V. All rights reserved. Page 8 of 92

215 For the meaning of the keywords, please refer to [RFC2119].

217 1.3.2 Mapping of High-Level requirements

220 e.g.: [MOB-007]

Copyright © 2022 EEBus Initiative e.V. All rights reserved. Page 9 of 92

225 2 High-Level description

226 2.1 Introduction

Measured values and

245 - Optimization of self-consumption

251 2.2 Detailed background information

Copyright © 2022 EEBus Initiative e.V. All rights reserved. Page 10 of 92

Photovoltaic Hybrid Battery

269 2.3 Actors

270 2.3.1 Monitoring Appliance

275 2.3.2 Battery

Copyright © 2022 EEBus Initiative e.V. All rights reserved. Page 11 of 92

279 2.4 Scenarios

Copyright © 2022 EEBus Initiative e.V. All rights reserved. Page 12 of 92

288 2.4.1 Scenario 1 - Monitor Battery identification

289 2.4.1.1 Description

Data point name Data point description Support High-Level

294 2.4.1.2 Conditions

Copyright © 2022 EEBus Initiative e.V. All rights reserved. Page 13 of 92

302 2.4.2 Scenario 2 - Monitor Battery state

303 2.4.2.1 Description

Data point name Data point description Support High-Level

307 This specification defines the following relations:

316 2.4.2.2 Conditions

Copyright © 2022 EEBus Initiative e.V. All rights reserved. Page 14 of 92

324 2.4.3 Scenario 3 - Monitor Battery DC power

325 2.4.3.1 Description

Data point name Data point description Support High-Level

330 2.4.3.2 Conditions

338 2.4.4 Scenario 4 - Monitor Battery DC current

339 2.4.4.1 Description

Data point name Data point description Support High-Level

344 2.4.4.2 Conditions

Copyright © 2022 EEBus Initiative e.V. All rights reserved. Page 15 of 92