ETSI TR 103 946 V1.1.1 (2023-10)

TECHNICAL REPORT
Methods for Testing & Specification (MTS);
Security validation of IoT architecture application and
conformity;
Case Study Experiences
2 ETSI TR 103 946 V1.1.1 (2023-10)

Reference
DTR/MTS-TST11Sec_IoTconf
Keywords
conformity, IoT, security, testing
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: +33 4 92 94 42 00  Fax: +33 4 93 65 47 16

Siret N° 348 623 562 00017 - APE 7112B
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° w061004871

Important notice
The present document can be downloaded from:
https://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
If you find a security vulnerability in the present document, please report it through our
Coordinated Vulnerability Disclosure Program:
https://www.etsi.org/standards/coordinated-vulnerability-disclosure
Notice of disclaimer & limitation of liability
The information provided in the present deliverable is directed solely to professionals who have the appropriate degree of
experience to understand and interpret its content in accordance with generally accepted engineering or
other professional standard and applicable regulations.
No recommendation as to products and services or vendors is made or should be implied.
No representation or warranty is made that this deliverable is technically accurate or sufficient or conforms to any law
rule and/or regulation and further, no representation or warranty is made of merchantability or fitness
and/or governmental
for any particular purpose or against infringement of intellectual property rights.
In no event shall ETSI be held liable for loss of profits or any other incidental or consequential damages.

Any software contained in this deliverable is provided "AS IS" with no warranties, express or implied, including but not
limited to, the warranties of merchantability, fitness for a particular purpose and non-infringement of intellectual property
rights and ETSI shall not be held liable in any event for any damages whatsoever (including, without limitation, damages
for loss of profits, business interruption, loss of information, or any other pecuniary loss) arising out of or related to the use
of or inability to use the software.
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and
microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2023.
All rights reserved.
ETSI
3 ETSI TR 103 946 V1.1.1 (2023-10)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 6
3 Definition of terms, symbols and abbreviations . 6
3.1 Terms . 6
3.2 Symbols . 6
3.3 Abbreviations . 7
4 Description of a general IoT Security architecture . 8
5 Testing and Assurance Process for IoT Applications Using the General IoT Security Architecture . 8
6 Experiences with different IoT Application Domains (Case Study Samples) . 9
6.1 Smart Home. 9
6.1.1 Description and Objectives . 9
6.1.2 Smart Home Pilot System . 10
6.1.2.1 High-level Architecture . 10
6.1.2.2 Detailed Description. 12
6.1.3 Results of the Evaluation . 15
6.1.3.1 Setup of the Smart Home Pilot Evaluation . 15
6.1.3.2 Prioritized Smart Home Pilot misuse cases . 18
6.1.3.3 Validation results per misuse case for the Smart Home Pilot . 18
6.1.3.4 Conclusion for the Smart Home Pilot . 18
6.2 Smart Grid . 19
6.2.1 Prosumer Cell Pilot System . 19
6.2.2 Results of the Evaluation . 24
6.2.2.1 Setup of the Prosumer Cell Pilot Evaluation . 24
6.2.2.2 Prioritized Prosumer Cell pilot misuse cases . 25
6.2.2.3 Validation results per misuse case for the Prosumer Cell pilot . 25
6.2.2.4 Conclusion for the Prosumer Cell pilot . 25
6.3 Unmanned air systems . 26
6.3.1 Description and Objectives . 26
6.3.2 Drone Operation Pilot System . 26
6.3.2.1 Drone infrastructure . 26
6.3.2.2 Drone Pilot System Functional Overview . 28
6.3.3 Results of the Evaluation . 29
6.3.3.1 Setup of the Drone Pilot Evaluation . 29
6.3.3.2 Prioritized Drone pilot misuse cases . 31
6.3.3.3 Validation results per misuse case for the Drone pilot . 31
6.3.3.4 Conclusion for the Drone pilot . 31
6.4 Automated driving . 32
6.4.1 Description and Objectives . 32
6.4.1.1 Introduction . 32
6.4.1.2 Scenarios . 32
6.4.1.2.1 Platoon driving . 32
6.4.1.2.2 Platoon merging. 34
6.4.1.2.3 Venue . 36
6.4.1.3 Connected Car Infrastructure . 37
6.4.2 Connected Car Pilot System . 40
6.4.3 Results of the Evaluation . 40
6.4.3.1 Setup of the Connected Car Pilot Evaluation . 40
6.4.3.2 Prioritized Connected Car pilot misuse cases . 42
ETSI
4 ETSI TR 103 946 V1.1.1 (2023-10)
6.4.3.3 Validation results per misuse case for the Connected Car pilot . 43
6.4.3.4 Conclusion of the Connected Car pilot . 43
History . 44

ETSI
5 ETSI TR 103 946 V1.1.1 (2023-10)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The declarations
pertaining to these essential IPRs, if any, are publicly available for ETSI members and non-members, and can be
found in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to
ETSI in respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the
ETSI Web server (https://ipr.etsi.org/).
Pursuant to the ETSI Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs,
including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not
referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become,
essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its

Members. 3GPP™ and LTE™ are trademarks of ETSI registered for the benefit of its Members and of the 3GPP
Organizational Partners. oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and of the ®
oneM2M Partners. GSM and the GSM logo are trademarks registered and owned by the GSM Association. ®
BLUETOOTH is a trademark registered and owned by Bluetooth SIG, Inc.
Foreword
This Technical Report (TR) has been produced by ETSI Technical Committee Methods for Testing and Specification
(MTS).
Modal verbs terminology
In the present document "should", "should not", "may", "need not", "will", "will not", "can" and "cannot" are to be
interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.

ETSI
6 ETSI TR 103 946 V1.1.1 (2023-10)
1 Scope
The goal of the present document is to compile case study experiences related to the security validation and assurance
for the integration and conformity of IoT applications with an existing IoT architecture in order to have a common
understanding in MTS and related committees and to support trustworthiness. Industrial experiences may cover but are
not restricted to the following domains: smart home, smart grid, unmanned air systems, automated driving.
2 References
2.1 Normative references
Normative references are not applicable in the present document.
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee
their long term validity.
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] IEC 60730-1: "Automatic electrical controls - Part 1: General requirements".
[i.2] IEC 61508: "Functional safety of electrical/electronic/programmable electronic safety-related
systems".
[i.3] IEC 61850: "Communication networks and systems for power utility automation".
[i.4] STANAG 4586: "Standard Interfaces of UAV Control System (UCS) for NATO UAV
Interoperability - AEP-84 Edition A".
[i.5] UL 991: "Tests for Safety-Related Controls Employing Solid-State Devices".
[i.6] UL 1998: "UL Standard for Safety Software in Programmable Components".
[i.7] ETSI TS 103 942: "Testing (MTS); Security Testing; IoT Security Functional Modules".
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the following terms apply:
MODBUS: network protocol used in the industrial manufacturing sector
3.2 Symbols
Void.
ETSI
7 ETSI TR 103 946 V1.1.1 (2023-10)
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
th
4G 4 Generation (mobile networks) also known as LTE
th
5G 5 Generation (mobile networks)
AD Attack Detection
AI Artificial Intelligence
API Application Programming Interface
AUDRIC AUtomated DRIving Core
C2 Command and Control
C4I Command, Control and Coordination Centre Infrastructure
CAM Cooperative Awareness Message
CAN Controller Area Network
CAV Connected and Automated Vehicle
CERTH CEntre for Research & Technology Hellas
DARIUS Integrated Deployable SAR chain with Unmanned Systems
DENM Decentralized Environmental Notification Message
DER Distributed Energy Resources
DFD Dataflow Diagram
DSRC Dedicated Short Range Communication
ECU Electronic Control Unit
EO/IR Electro-Optical/Infra-Red
FEAM Front-End Access Management
GCS Ground Control Station
GGCS Generic Ground Control Station
GGS Generic Ground Station
GPS Global Positioning System
GPU Graphics Processing Unit
GSM Global System for Mobile communication
ICT Information and Communication Technology
ID Identity
IEC International Electrotechnical Commission
IMU Inertial Measurement Unit
IoT Internet of Things
IoTAC Security by design IoT development and certificate framework with front-end Access Control
IR Infrared
IT Information Technology
ITI Informatics and Telematics Institute
ITS Intelligent Transportation Systems
JSON JavaScript Object Notation
MODBUSRTU MODBUS Remote Terminal Unit
MODBUSTCP TCP-based MODBUS protocol
MQTT Message Queueing Telemetry Transport
MTS Methods for Testing & Specification
nZEB near-Zero-Emission Building
OBU On-Board Unit
PC Personal Computer
PLC Programmable Logic Controller
PMR Personal Mobile Radio
PV PhotoVoltaic
SAE Society of Automotive Engineers
SEGOVYA-RT SafE Generator of Vehicle trajectory using lAne information on Real-Time
SITL Software-In-The-Loop
SME Small and Medium Enterprise
STANAG NATO Standardization Agreement
STRIDE Spoofing, Tampering, Repudiation, Information disclosure, Denial of service and Elevation of
privilege
TCP Tactical Command Post
TLS Transport Layer Security
TR Technical Report
ETSI
8 ETSI TR 103 946 V1.1.1 (2023-10)
UAV Unmanned Aerial Vehicle (drone)
UDP User Datagram Protocol
UI User Interface
UL Underwriters Laboratories
V2V Vehicle to Vehicle
V2X Vehicle to Everything
VPN Virtual Private Network
VTOL Vertical Take-Off and Landing
WC Water Closet ®
Wi-Fi Wireless Fidelity
4 Description of a general IoT Security architecture
Refer to [i.7], clause 4 for a description of the general IoT security architecture upon which the present document is
based.
5 Testing and Assurance Process for IoT Applications
Using the General IoT Security Architecture
Integration validation of modules is a process aimed at ensuring that the modules successfully integrate into the pilot
environment and meet the required security requirements. The process involves several steps:
1) Identifying generic misuse cases relevant to the pilot (critical, high priority). These cases are grouped by
processes (data collection process, storage, processing, control process, client interface).
2) Identifying pilot-specific misuse cases.
3) Identifying pilot-specific security baseline requirements addressing the generic misuse case.
4) Identifying which IoTAC modules prevent which misuse cases by implementing the security baseline
requirement.
5) Checking if and how the IoTAC module is integrated into the pilot environment. To do this, the following
steps are taken:
a) Checking the architectural integration of the IoTAC modules.
b) Checking which aspect of the security baseline requirement is implemented by the IoTAC module.
c) Checking if the integration of the IoTAC module allows the realization of the security requirement in the
context of the pilot, e.g. if the related pilot misuse case can be prevented.
The process of integrating module validation is essential in ensuring the secure integration of modules and the
maintenance of the integrity and security of data and systems within the pilot environment. One of the main goals of
this process is to identify and address any potential misuse cases to prevent them and guarantee the overall security of
the system. To achieve this, security baseline requirements provide a set of guidelines to follow. By identifying which
IoTAC modules address which misuse cases, it is possible to ensure that the appropriate measures are in place to
mitigate these issues. Additionally, it is important to carefully check the integration of the IoTAC modules into the pilot
environment to verify that they can effectively address the identified misuse cases and meet the security requirements.
The process of integrating module validation has two key outcomes. The first outcome is a determination of which
misuse cases are covered using IoTAC modules. The second outcome is potential findings that should help the pilot's
developers increase security by completely addressing their misuse cases when using the IoTAC modules.
ETSI
9 ETSI TR 103 946 V1.1.1 (2023-10)
6 Experiences with different IoT Application Domains
(Case Study Samples)
6.1 Smart Home
6.1.1 Description and Objectives
The objective of the pilot is to validate the components and services developed by the loTAC project in the smart home
application domain. The Smart House of CERTH provides an ideal environment for this purpose. In order to achieve
the project's objectives, a Smart Home Pilot System over the existing infrastructure of CERTH has been defined by
specifying the basic functional requirements and use-cases and identifying the most important non-functional
requirements as well. A STRIDE-based threat- analysis has been executed to derive security requirements.
CERTH/ITI Smart House introduces the first house in Greece that combines enhanced construction materials and
intelligent ICT solutions creating a future-proof, sustainable and active testing, validating, and evaluating environment.
The house is representative of a single-family, detached residential building and is already equipped with many loT,
smart home solutions that provide a lot of information about its operational characteristics. More specifically, it
provides various innovative smart loT-based technologies with provided Energy, Healthcare, Big Data, Robotics and
Artificial Intelligence (AI) services. The Smart House is equipped with a vast variety of sensors, actuators, smart home
devices and intelligent robots. The building can operate as a microgrid by utilizing the proximity PhotoVoltaic (PV)
plant and the battery unit available.
The Smart House is a single two-floor building (Figure 1). It is divided into two principal sections, the main household
(living room, kitchen, bedrooms, hallways, WC, bath, etc.) and three ancillary control rooms on the left and right wings
of the building. It does not have physical connection with other buildings.

(Source: IoTAC project)
Figure 1: nZEB Smart House at CERTH/ITI's premises
The Smart House Infrastructure provides appliances for supporting applications of highly diverse domains, as illustrated
in Figure 2.
ETSI
10 ETSI TR 103 946 V1.1.1 (2023-10)

Figure 2: Smart Home infrastructure
Two domains that the CERTH/ITI Smart House supports, which are critical from a security viewpoint, are the Energy
and Healthcare domains. Applications that belong to these domains are supported by the following infrastructure:
• Energy related equipment (e.g. smart meters, dimming and on/off actuators, environmental sensors, occupancy
sensors, smart plugs, smart appliances, photovoltaics, batteries, etc.) that monitors the consumption,
production and the conditions of the entire building, while automated algorithms can implement automation
and/or efficiency scenarios while respecting occupant preferences.
• Health related equipment (e.g. blood pressure, glucose, oxygen levels, panic buttons, motion sensors, etc.) that
monitors a variety of biometric attributes, a process that enables the extraction of valuable data (such as
patterns and biometric attributes) through intelligent processing towards preventing or timely reacting to
situations that could otherwise lead to harmful or even fatal outcomes.
6.1.2 Smart Home Pilot System
6.1.2.1 High-level Architecture
The Smart Home Pilot System comprises components and services related to the consumer energy and the healthcare
domains. The context diagram of the system is shown in Figure 3.
The Smart Home has the ITI Smart Home Platform, which acts as a complete monitoring and control framework, just
like a management system. Through the main web dashboard, the user can interact with the IoT Infrastructure of the
Smart Home. More specifically, the platform provides several software applications in the form of standalone widgets,
which allow the user to monitor data retrieved from different sensors through easy-to-understand visualizations, as well
as to invoke actuators and activate appliances.
ETSI
11 ETSI TR 103 946 V1.1.1 (2023-10)

Figure 3: ITI Smart Home Pilot System DFD Diagram (first level of decomposition)
The main purpose of the ITI Smart Home Platform is to allow users to live in a comfortable environment while saving
money by improving the energy efficiency and optimal health. This can be achieved by optimizing the day-to-day usage
of the system to avoid unnecessary actions and overall to save money from their bills.
The high-level architecture of the ITI Smart Home Platform is based on the client-server approach. The User Interface
(UI) consists of the web-based dashboard that allows user interaction with the underlying infrastructure. The back-end
component provides the required services, data, and management of requests for the front-end functions to work. The
high-level conceptual view of the CERTH ITI Smart Home Platform is shown in Figure 4.
The structure of the ITI Smart Home platform follows a centralized approach (i.e. all IoT components interact with the
platform services via RESTful API interfaces). First, the data monitoring process accumulates all necessary data from
sensors/actuators locally on gateways. Next, it propagates them to the respective databases (i.e. InfluxDB and
MongoDB) via a dedicated RESTful API. Finally, the UI component retrieves the data to create intuitive plots and
optimize the operation of the system. The API handles the data in JavaScript Object Notation (JSON) format, which is a
standard and human-readable file format that is generally used for server communication. The UI of the platform is
implemented with Angular, while the backend is written in Node.js.
ETSI
12 ETSI TR 103 946 V1.1.1 (2023-10)

Figure 4: ITI Smart Home Platform high-level conceptual view
6.1.2.2 Detailed Description
The ITI Smart Home platform requires a user authentication to ensure data security. User authentication procedure is
based in several secure encryption algorithms. ITI Smart Home login page is shown in Figure 5.
ETSI
13 ETSI TR 103 946 V1.1.1 (2023-10)

(Source: IoTAC project)
Figure 5: The ITI Smart Home platform login page
After the mandatory login procedure, user is transferred to the ITI Smart Home Platform home page, from which user
has an option to access various modules (i.e. Energy, Healthcare, Localization, Water, Environmental, Retrofitting, and
Demand Response), as shown in Figure 6. As mentioned in the previous clause, for the IoTAC project Energy and
Healthcare modules have been selected as the most representative ones.

(Source: IoTAC project)
Figure 6: ITI Smart Home Platform home page
After clicking on the Energy module, the user is transferred to the Energy panel, where he can see a summary of the
various system and environment conditions. In the Microgrid tab, user can investigate various internal and external
conditions as illustrated in Figure 7. On this tab, the user can monitor the building's energy consumption (Figure 8).
ETSI
14 ETSI TR 103 946 V1.1.1 (2023-10)

Figure 7: Weather Conditions and Energy Flow

Figure 8: Energy Consumption/Production - measurements & cost
Besides monitoring, user has an option to invoke the following services:
• prediction (short-and long-term);
• microgrid Optimization (e.g. adaptive daily schedule, initial optimal daily schedule, daily financial balance,
battery operation, etc.); and
• to monitor values of various key performance indicators (e.g. energy purchase, energy selling, reduction in
overall energy demand, etc.).
ETSI
15 ETSI TR 103 946 V1.1.1 (2023-10)
After clicking on the Health module from the ITI Smart Home platform homepage, the user is transferred to the
Healthcare Panel where he can see a summary of various health related parameters and conditions (Figure 9).

Figure 9: ITI Smart Home Healthcare Panel
6.1.3 Results of the Evaluation
6.1.3.1 Setup of the Smart Home Pilot Evaluation
Currently, regarding authentication and user access control on the resources of the Smart Home System, a combination
of basic authentication (i.e. username and password pair) and role-based access control is used. Each user is registered
and authenticated by the Smart Home System by providing a valid username and password pair. In addition, each user
is assigned a role, which defines to which resources the user has access and what actions the user can perform on these
resources. This scheme is considered to be adequate for some cases, but it has room for improvement.
Regarding the mechanism for reporting measurements coming from the Smart Home Assets to the Smart Home Admin,
right now there is no policy established for identifying if the reported measurements are accurate or not, or more
specifically, if they have been altered in a malicious way by an intruder. This has been identified as a major
shortcoming since it is very important for the administrator of the Smart Home System to know that the reported
measurements from the Smart Home Assets reflect the reality and that they have not been changed in any way by an
attacker.
Both aforementioned security concerns can be alleviated by the deployment of IoTAC modules in the Smart Home
System. More specifically, the security concern about unauthorized access to the resources of the Smart Home can be
alleviated by the IoTAC FEAM (Front-End Access Management) module, which will enhance the way users are
registered to the Smart Home System and how they get access to its resources. In addition, the deployment of the
Attack Detection (AD) and Honeypot IoTAC modules within the Smart Home System's architecture, will introduce a
mechanism for identifying the false (i.e. altered) measurements coming from the Smart Home Assets.
ETSI
16 ETSI TR 103 946 V1.1.1 (2023-10)

Figure 10: Overview of the Smart Home architecture

Figure 11: A detailed overview of the logical architecture of the Smart Home Pilot
ETSI
17 ETSI TR 103 946 V1.1.1 (2023-10)
Table 1: Smart Home Assets
(Source: IoTAC project)
ETSI
18 ETSI TR 103 946 V1.1.1 (2023-10)
6.1.3.2 Prioritized Smart Home Pilot misuse cases
Table 2: Prioritized misuse cases for the Smart Home Pilot
Associated STRIDE
ID Misuse case Priority
threats
SN_EN_2 Leaked power consumption and lighting data allows the I Medium
attacker to deduce whether the occupants of the smart house
are home, which is a privacy breach.
SH_EN_7 Incorrectly controlling switches of a smart house may cause S, T High
financial loss for the occupants (e.g. constant on/off
commands may damage home appliances) and/or accidents
(e.g. fire caused by remotely controlled oven).
SH_EN_9 Leaked control commands allow the attacker to learn which of I Medium
the publicly available billing options the occupants have
chosen, which is a privacy breach.
SH_EN_11 Incorrectly displaying power generation and/or consumption S, T Medium
data, or price per unit data may cause occupants to
mismanage their power source preferences, potentially leading
to financial loss.
SH_EN_12 Leaked power management configurations and/or commands I Medium
set via the client interface may allow to attacker to learn e.g.
absence of the occupants, which is a privacy breach.

6.1.3.3 Validation results per misuse case for the Smart Home Pilot
During the validation of the Smart Home Pilot an assessment of the system's architecture and security modules was
conducted. The goal was to determine if the system met the necessary security requirements and was suitable for its
intended use.
After conducting a document review, it was determined that the system's architecture and IoTAC modules were
effective in protecting the system from potential security threats. However, during the evaluation, it was discovered that
the RESTful API should be protected, MQTT should be protected (e.g. TLS) because the protocol itself does not
provide any security mechanisms. In addition, the Modbus should be protected (e.g. TLS) because the protocol itself
does not provide any security mechanisms as well.
It is concluded that the system's architecture is secure for its intended use, but recommendations are given to the
system's operator to consider protecting the RESTful API, MQTT and Modbus as mentioned above to minimize
potential security risks and to ensure the system's security level is kept high. These findings should be taken into
consideration in future iterations of the system to further enhance its security.
6.1.3.4 Conclusion for the Smart Home Pilot
During the validation of the Smart Home Pilot an assessment of the system's architecture and security modules was
conducted. The goal was to determine if the system met the necessary security requirements and was suitable for its
intended use.
After conducting a document review, it was determined that the system's architecture and IoTAC modules were
effective in protecting the system from potential security threats. However, during the evaluation, it was discovered that
the RESTful API should be protected, MQTT should be protected (e.g. TLS) because the protocol itself does not
provide any security mechanisms. In addition, the Modbus should be protected (e.g. TLS) because the protocol itself
does not provide any security mechanisms as well.
It is concluded that the system's architecture is secure for its intended use, but recommendations are given to the
system's operator to consider protecting the RESTful API, MQTT and Modbus as mentioned above to minimize
potential security risks and to ensure the system's security level is kept high. These findings should be taken into
consideration in future iterations of the system to further enhance its security.
ETSI
19 ETSI TR 103 946 V1.1.1 (2023-10)
6.2 Smart Grid
6.2.1 Prosumer Cell Pilot System
Smart grids became important part of production and distribution of electrical energy. Their role in the safety of the
service is determinative. The flat load on the grid can contribute to the optimal use of the network's capacity, which
reduces the need for additional investments for extending the distribution network.
Prosumer cells are the key elements of the future smart grid. A prosumer cell is capable to behave either as producer or
as customer in the grid. It usually contains small local plants (most frequently photo-voltaic modules or wind turbines),
switches to change between producer consumer or off-line states, energy storage, and intelligent controller(s) with
sensors and actuators.
A smart grid - as a Distributed Energy Resources (DER) system - is made up of a multitude of prosumer cells. Their
activity in the grid is controlled by their user's interests. There are two main kind of users, the cell's owner and the grid
operator. The cell owner and the grid operator both want to maximize their profits, but they have conflicting goals. Cell
owners want to optimize the use of their own energy resources. The grid operator tries to balance the load on the grid.
The coordination of their activity is based on dynamical pricing, extended with some contract-based rights for difficult
or emergency situations. The cells work partly in automatic manner, partly remotely controlled by commands.
The key issue is the safe bidirectional information flow both internally between the local units of the cell and externally
with the remote command interface. Commands, measured status (actual, emergency, etc.) and integrated data (long
term integrated energy balance, etc.), financial information (actual price offered by the controller and by the prosumer,
agreed delivery price, price for exceptional set up of energy flow direction under compulsion, etc.) are the main
important components of the information flow.
The pilot will be based on a simple, single-cell experimental prosumer cell configuration installed by the manufacturer
and operated by the project. The pilot's objective is to improve the security and confidence of the system by
implementing the IoTAC solutions.
A relatively small, 3,5 kW peak capacity solar powered prosumer cell was constructed at the Balatonfired site. The
system also has an energy storage capacity of 5 kWh. This system is connected to the local power grid. This installation
will be mainly used as a development and experimental platform for DER systems, remote management of DER assets,
and provide a testbed for predictive maintenance algorithms. The system will be capable to operate as part of an
extended DER management system as a local DER controller with two main electric power components: the solar cell
and the battery pack, according to Figure 12.
ETSI
20 ETSI TR 103 946 V1.1.1 (2023-10)

(Source: IoTAC project)
Figure 12: DER system hierarchy
The elements in the rectangle represent the prosumer cell under discussion. The role of Figure 12 is to show a possible
hierarchical structure of a larger power grid system and the position of the cell at the bottom level of the hierarchy.
Figure 12 also shows that the next obvious step for security improvement is to install a DER Gateway with security
functions.
A simplified schematic of the cell is shown in Figure 13.
ETSI
21 ETSI TR 103 946 V1.1.1 (2023-10)

Figure 13: Schematic of the prosumer cell
The prosumer cell includes 9 solar panels (PV modules), a hybrid grid connected inverter, a data logger, an energy flow
control device, battery back-up, an environmental monitoring unit and an e-car charger.
The control unit of the cell is an inverter combined with a Smart Logger. The battery (local storage) has a dedicated
load/charge controller. Each PV module delivers the generated energy to the inverter. The e-car charge station is
controlled by the cell controller. The allowed power, the time of charging, the source of the energy for charging are the
most important parameters which can be adjusted by the cell's owner.
The main goal of the system is to convert energy coming from the solar panels for local consumption. If the produced
energy exceeds the actual local consumption, the prosumer cell has the possibility of either storing the excess energy in
the local battery or exporting it to the power grid. The decision is largely based on the cell owner's preference, however
in certain situations, the cell-owner or the grid operator may prohibit exporting of energy above a certain power level
(by issuing output power limitation commands).
The system works partly automatically, partly by commands given by the cell's owner or the grid operator (also called
DER manager).
The energy flow direction is regulated by the smart power sensor. The local need for energy (e-car, charging of the local
battery, other local load) has the highest priority. If the real-time generation of energy is not enough to serve these
needs, depending on the price set-up, the generated energy will be extended by power from the battery or from the grid.
If the generated energy exceeds the local need, the smart power sensors set up the energy flow towards the grid. The
smart power sensor has a smart meter function too. It measures the energy flow in both directions. The accumulated
values are stored with time stamps and can be queried by commands.
Communication of the internal functional units is crucial for the automatic functions. Internal connections of the
components are mainly MODBUSRTU connections.
There are two main external connection links to the cell: ®
• Wi-Fi through a manufacturer provided closed source application, that provides local access to data. This ®
interface should work during the installation process. In order to improve security, the Wi-Fi network will be
disabled once setup of the cell is complete.
• Public Ethernet connection. VPN can be introduced. There is MODBUSTCP (with TLS security)
communication currently implemented on the public network, but IEC 61850 [i.3] is also a requirement for
remote grid Controller operation. Most of the functional units can be accessed directly also by MODBUSTCP.
The context diagram of the Prosumer Cell Pilot System is shown in Figure 14.
ETSI
22 ETSI TR 103 946 V1.1.1 (2023-10)
The system should provide at least 3 different roles with separate levels of access rights, namely, Installer, DER
manager and Owner:
• The Installer is the person who sets up the system and has the highest level of access rights.
• The Owner is the person, whose interest is to operate the cell in the most efficient way from local perspective.
• The DER manager - or grid-operator - is the person (or a robot) whose interest is to operate the grid in the
most efficient way from global perspective.

Figure 14: Prosumer Cell Pilot System Context
Other external connections:
• Power grid is the main physical connection for exporting or importing energy. Integrated sensors convert the
actual physical parameters of the power line (voltage, frequency, current, power) to usable data format for the
system.
• Solar panels (PVs) can be considered as a single external hardware unit with its own power optimizer. The unit
can be reset by the system, and status information as well as panel temperature can be read.
• Environment is also monitored using different sensors like temperature, humidity, wind-speed, irradiation.
These sensors are built in devices of the cell.
The component diagram of the cell is shown in Figure 15. Only the logical interfaces are represented, the physical
electrical connections are only implied where they also serve as data sources (e.g. power measurement and power-line
based communication).
ETSI
23 ETSI TR 103 946 V
...