-IoT principles catalogue

Principle ID

Principle

Description

Rationale

Implications

IoT-1

The IoT system allows modules to be changed independently of each other

Definitions relevant to the principle:

·   Here, the term module means: A logical collection of functions within the IoT system; - Or “Any of a number of distinct but interrelated units from which a program may be built up or into which a complex activity may be analysed.”

·   Maintainability is defined as a measure of how well adapted a system is to management.

The modules making up the IoT system can be changed or upgraded to a new version as the architecture evolves without adversely affecting data transport or the functionality of the surrounding modules.

A module can be changed or upgraded to a new version without the need to change the surrounding modules or the information management of the system, including information models and metadata.

The modular perspective thus applies to both the IoT system's constituent functions and data/information management.

It is important that the design and implementation of modules are based on a clarity of interfaces so that the modules are made compatible with each other.

The IoT system allows other IoT solutions to be connected to certain modules or at different levels. For example, a property control system that stores data to the shared storage area but is otherwise a standalone system.

·   This principle is important to reduce lock-in effects.

·   To acquire maintainability over time.

·   To reduce costs, improve functionality and improve quality over time.

·   Enables architectural and technical flexibility over time.

·   It is important to be able to put each module out to tender in view of the Public Procurement Act (LOU) and the Defence and Security Procurement Act (LUFS).

·   Makes it possible for sensors and actuators to come from multiple suppliers and be exchangeable.

·   Makes it possible to change modules and migrate/export information when a module is changed or decommissioned.

·   Contributes to EIF Principle 5: technological neutrality and data portability

·   Contributes to Principle M6 “Life-cycle costing is taken into account when investing in and financing digital solutions” in SALAR’s “Utveckling i en digital tid” [Development in a digital age].

·   There may be longer start-up time and increased responsibility for the procuring organisation, as all interfaces and modules need to be defined.

·   There will be a shift of responsibility towards the procuring organisation, e.g. when integration is involved. More thought is therefore required in terms of architecture and IT strategies.

·   More work may be needed to achieve the intent of the principle, as existing building management systems are not aware of or prepared for data, information and services from IoT systems. It is therefore important that the procurer takes this into account in the design of the IoT system.

·   From a business perspective, it is important that agreements and procurement support the exchangeability of modules. Suppliers should describe how this can be done and how this is priced.

·   Agreements with suppliers need to support the principle, so that there are no contractual locks that prevent exchangeability

IoT-2

Data, information and context awareness of the IoT system are preserved during module and system changes

Data, information and context awareness survive system changes and public procurement. The procuring organisation therefore needs to take full control of how data is stored and used within the organisation.

The procuring organisation needs to ensure they obtain ownership and usage rights to the data, information and context awareness created in the IoT system. Without this, it is difficult to gain future benefit from the information collected.

Context awareness is a key component of an IoT system. It requires that the municipality or region builds a context-based structure that covers the needs of the entire organisation. It needs to be expandable to cover the needs of the future rather than just the needs expressed today.

·   Data is what endures and is an asset.

·   This principle contributes to fulfilling EIRA Principles 4, 5, 10, 11

·   The procuring organisation wants reasonable costs for moving data.

·   Makes it possible to change modules and migrate/export information when a module is changed or decommissioned.

·   The procuring organisation is always able to get the data sets created in each module in a standardised format.

·   Contributes to EIF Principle 11: preservation of information

·   There may be longer start-up time and increased responsibility for the procuring organisation, as all interfaces and modules need to be defined.

·   Understanding on the part of the procurer is required for the data and information set that builds the context awareness and how it will be managed in the short and long term.

·   It is the procurer’s responsibility to ensure that sensor data is translated into useful data.

·   There is a risk that adherence to the principle could result in a highly complex or sluggish IoT system if the structure is not well thought out from the outset. More thought must therefore be put into the architecture and IT strategies in initial phases in the procuring organisation.

·   In agreements with suppliers, the procuring organisation needs to ensure they obtain ownership and usage rights to the data, information and context awareness created in the IoT system.

IoT-3

The information modules of the IoT system are built in a horizontal overarching level and specific vertical levels

To achieve information interoperability between systems and applications, information modules need to be loosely coupled to each other. This can often be divided into three levels; the horizontal top level, e.g. oneM2M, that ties together vertical levels, e.g. the information model for SAREF for smart homes. The third level is the application level, where the information model is tailored to the needs of a specific application.

A best practice is to build the information models on standardised and widely-accepted ontologies.

Horizontal ontologies – Interoperability between vertical ontologies
Vertical ontologies – Interoperability within specific business domain
Application ontology – Within a specific application

·   This ensures interoperability both internally and externally.

·   This ensures that the information is understood independently of data and systems, thereby reducing the risk of lock-in effects and excessively high transformation costs.

·   The information models become manageable and reusable.

·   Follows FAIR principles for data; see FORCE11

·   Follows DIN 91357:2017-12 section 7.2.6 Extended Interoperability, standard for reference architecture for Open Urban Platform.

·   Contributes to Principle 5 “Reuse from others” and Principle 6 “Ensure that information and data are transferable” in DIGG’s (Agency for Digital Government) “Grundläggande principer för digital samverkan” [Fundamental principles for digital collaboration]

·   Contributes to Principle M9 “Open international standards are used for information exchange; deviations should be well justified” in SALAR’s “Utveckling i en digital tid”.

·   Expertise in the field is required

·   Requires that suppliers understand what standards exist and are able to implement standardised information models.

·   Requires that the procurer creates an incentive for suppliers to solve this.

·   Requires that procurers and procuring organisations are active within the standardisation organisations to ensure that standardisation needs are met.

IoT-4

The IoT system enables the processing and enrichment of information [in different ways]

Information can be processed and enriched depending on the needs to be resolved. Examples:

·   Convert data to the IoT system’s information model.

·   The IoT system includes mechanisms to process data, whether this is the ability to create events, analyse streaming and/or dormant data, or include or exclude data from storage/processing. Examples:

o  quality controlled,

o  combined with business data,

o  origin labelled,

o  interpolated/extrapolated, sampled,

o  combined with context information.

·   EDGE processing of data-intensive/data-rich sensors/solutions; local processing possible. EDGE processing may also be appropriate when processing sensitive information (images/video, personal data) so that this set of information is “terminated” there and not passed on into the IoT system.

·   Basic function to be able to use the IoT system to create applications that deliver benefits to the organisation.

·   Basic function to be able to create context in the IoT system. Context awareness can be achieved in a subsequent step.

·   Provides greater opportunity in the use of information from the IoT system as follows:

o  Information can be more easily consumed by different applications

o  Information can be more easily adapted to different applications

·   The same information can exist in different degrees of refinement at different places in the IoT system, making it important to maintain good order for all information and how the processing of data is done.

·   Requires expertise in how the IoT system’s information set and information model are structured and how to manage these.

·   Agreements with suppliers and the chosen architecture need to be linked so that operating and management costs can be managed efficiently.

IoT-5

The IoT system supports the storage of data in different ways based on the nature of the information and its usage needs

Often, the same or very similar data needs to be stored in different storage due to performance or other requirements, or because the organisation wants to change storage solution. For example, the storage needs to:

·   be able to handle data that is time series based

·   make it possible to comply with retention policies, to be able to purge data after a specific period of time.

·   meet the organisation’s information security, regulatory and policy requirements

·   be able to save unstructured and structured data, images, video, etc.

·   be able to manage data and information throughout its lifecycle, e.g. raw data, verified raw data, processed raw data, published data and archived data. This includes how data is purged in each step.

·   Different business needs have different information security requirements that need to be met

·   Well-designed storage allows information to be analysed in a structured way

·   Makes it possible to manage storage costs

·   Enables broader use

·   A public procurer needs to comply with and adhere to the information management plan decided within the respective organisation.

·   A risk-based and systematic information security approach by the procurer is a prerequisite before and during the storage of information for further use or processing/enrichment

·   IoT systems may result in large data sets and/or contain sensitive information. The organisation therefore needs to identify which data is to be stored and assess which data is important to store, archive and purge, respectively.

·   A public procurer needs to draw up and adhere to the information management plan decided within the respective board. The technical solution therefore needs to support the procurer with this.

·   The procurer needs to understand what options are available to meet the needs of the IT system.

·   Agreements with suppliers and the chosen architecture need to be linked so that operating and management costs can be managed efficiently.

IoT-6

The IoT system is capable of meeting a defined risk and impact level [to achieve the intended information security]

An application of the IoT system has a specific risk and impact level. This level must always be equal to or lower than the risk and impact level that the IoT system must be able to meet for the application. The following is therefore required:

1. An application’s need for IoT must express what requirements must be met for it to meet its risk and impact level. These need to be evaluated against the IoT system to assess the suitability or need for expansion to meet the requirements. For each application, an assessment must therefore be made as to whether the IoT system can be used.

1. The IoT system needs to have well-described capabilities, specifying what it can deliver, as well as a relevant technical description, so that applications can understand what they can expect from the IoT system.

A risk and impact assessment can reasonably be done using SALAR’s “Klassa” tool with its guide “Klassa för IoT” [Klassa tool for IoT], where the whole chain from sensor/actuator to application is addressed.

·   Central to achieving and maintaining the required information security.

·   An IoT system capable of handling very large risks and impacts will be expensive to acquire and manage.

·   When the capabilities of an IoT system are well described, it is easier to scale up, achieve an increased rate of innovation and reach a flexible solution that can be used by many.

·   Better support to information owners

·   Support organisations and IT in handling access and permissions to information and services

·   Contributes to Principle 9 “Make it secure” in DIGG’s “Grundläggande principer för digital samverkan”

·   Contributes to Principle M8 “Information security work is done systematically and risk-based” in SALAR’s “Utveckling i en digital tid”.

• An application needs to clearly express what requirements it places on the IoT system to meet its risk and impact level.

• From a risk and impact perspective, an application is as strong as its weakest link. Solutions should therefore be examined to evaluate them against a general IoT system.

• Evaluate the suitability of the IoT architecture based on the specific risk or impact levels of the application.

• Different IoT systems may be required for specific purposes, depending on the risk and impact level.

• The procurer needs to ensure that the information security in all modules of the IoT system work together. Please refer to sections 4.1, 4.2, 4.3 and 6 (High level recommendations) i ENISA Baseline Security Recommendations for IoT or similar.

• The procurer needs to ensure that the SLAs of all suppliers involved in the IoT system are sufficient to ensure the specific risk and impact level of the applications.

• The procurer needs to assess whether the supplier's organisation meets the requirements for internal information security procedures.

• The procurer needs to ensure that the suppliers involved meet the requirements set to satisfy the information security requirements.

• The procurer needs to ensure that the SLAs of the suppliers involved can be changed, either upwards or downwards, at a controlled cost.

• The organisation needs to define what risk and impact level it will set requirements at.

• The procuring organisation may need to seek the approval of county councils or other authorities to set up sensors in public places.

• The procurer always needs to ensure that informationsecurity i ensured for the whole chain of information flow, in the IoT case from IoT-device to application. In order to do this a segmentation based on risc and consequence can be a resonable way. Segmentation can be done for connectivity, network, data storage or place of operation.

• A procurer that is to implement IoT solutions, especially involving integrated subsystems, needs to adapt to the ENISA principle of “security by desing”. Obviously very subsystem needs to adapt to the “security by design” principle.

IoT-7

The IoT system supports digital management of physical IoT devices and their connection to the IoT system.

This principle handles the initial provisioning of IoT devices and the digital management of IoT devices during their lifecycle.

Lots of IoT devices will be connected to the IoT system. It is therefore important that the IoT system is flexible and can handle different physical IoT devices and connectivity.

In order to know at any given moment what IoT devices exist and what status they have in terms of connectivity and function, the IoT system needs to:

1. be able to manage updates of physical IoT devices, e.g. firmware, configurations, decoding via the IoT system.

1. manage provisioning of the physical IoT devices, which are linked to central management of the virtual IoT devices. An automatic and dynamic list of all physical IoT devices provisioned to the IoT system is thereby obtained.

Definitions:

·   Provisioning: the process of how a virtual IoT device is created and how a physical IoT device is connected to the IoT system.

·   Creates the conditions for maintainability and an overview of which physical IoT devices are available within the IoT system

·   Know at any given moment what sensors are present and what status they have in terms of connectivity and function.

·   Facilitates troubleshooting of physical IoT devices.

·   Requires expertise in the IoT system's architecture and the processes required for lifecycle management of IoT devices.

·   Requires the existence of an organisation (and, where relevant, agreements with suppliers) to operate and manage IoT devices so that the IoT devices meet the requirements of the various applications.

IoT-8

The IoT system is capable of handling virtual IoT devices

Definitions relevant to the principle:

·   “Virtual IoT device” – Represents a physical IoT device or a simulated IoT device.

·   “Simulated IoT device” refers to a virtual IoT device that is not directly connected to a physical IoT device, e.g. a computed value. The working group has limited itself to IoT devices, i.e. sensors or actuators.

Within the IoT system, the virtual IoT device is that object that applications interact with. The virtual IoT device, in turn, handles the interaction with the physical IoT device.

The virtual IoT device holds information and metadata about itself.

A virtual IoT device can deliver a calculated value from a physical value or even exist without the existence of a physical IoT device.

A virtual IoT device can be directly connected to a physical IoT device or be a simulated IoT device that gets its data from e.g. a computed value, information sources on the internet, data from a SCADA system or another IoT system, etc.

NOTE: ISO 20924 does not cover simulated, virtual IoT devices, which is a limitation that is not considered reasonable. In this work, the working group therefore expanded with simulated IoT devices as a subset of virtual IoT devices.

·   By distinguishing between physical and virtual IoT devices, application development is simplified and maintainability is increased.

·   Distinguishing between virtual and physical IoT devices is a prerequisite for connecting IoT systems for both general horizontal solutions and vertical solutions.

·   Helps to create loose connections in the IoT system and thus contributes to the exchangeability of modules and physical IoT devices.

·   A virtual representation of the physical IoT device is important, as the application cannot have direct contact with the physical IoT device.

·   It is important to be able to manage the information in the same way even if the source of the information is not always a physical IoT device. For this reason, we need to be able to manage simulated IoT devices.

·   No implications identified

IoT-9

The IoT system enables the management and orchestration of event-driven architecture

Definition: Event-driven architecture

See Wikipedia

Definition: Orchestration

See Wikipedia

In the IoT system, event-driven information moves between nodes, where information is enriched or processed for applications to make use of the information. It is therefore key to keep track of information flows, which is done through good orchestration tools.

Within and outside of the IoT system, several applications will need to make use of the data and information from virtual IoT devices. The function of controlling and orchestrating the flow of information within and outside of the IoT system is therefore a central aspect of a well-functioning IoT system.

In the IoT system, it needs to be possible to define produced and consuming services for both internal and external information flows. This is often resolved with publish/subscribe services, and there are also elements of ETL (Extract/Transform/Load) services and queue management related to this.

Examples of solutions for this are Apache Kafka, MQTT, Amazon Kinesis, Google Sub/Pub, and Microsoft Data Factory. These services need to describe which APIs/access points can be used.

·   A fundamental function in IoT systems to enable them to share and use IoT information in and between different systems and operations.

·   A prerequisite for achieving Principle 4: The IoT system enables the processing and enrichment of information [in different ways]

·   The IoT System relies on the flow of information between nodes, where information is enriched or processed (Principle 4). To achieve scalability and maintainability, it is key to keep track of information flows, which is done through good orchestration tools.

·   Requires good knowledge of the organisation’s information models and data management rules in the different applications.

·   The design of event-driven architecture can strongly influence information management costs in an IoT system. It is therefore important for the procurer to ensure the design is cost-effective and based on the requirements of the respective application.

·   Agreements with suppliers and the chosen architecture need to be linked so that operating and management costs can be managed efficiently.

IoT-10

The IoT system’s information, services and data are available for applications

Definition:

Application refers to a computer application, system or service that uses the information, data and services of the IoT system.

The IoT system provides access to information, data and services with appropriate permissions (may also refer to open data without restrictions).

Information from sensors, event-driven information or historical data is made available through the IoT system. It should also be possible to grant access to controller services (e.g. switch off a lamp).

To achieve the principle, requirements should be set regarding which interfaces (APIs) are exposed by the IoT system. A good guideline to follow is DIGG’s principer för tillgängliggörande av information [Principles for making information available] and vägledning för att tillgängliggöra information [Guide for making information available].

·   Access to information, services and data in a way that is stable over time is a prerequisite for achieving usability and maintainability of the applications that use the IoT system.

·   For increased maintainability of the applications using the IoT system interfaces (APIs), the interfaces need to be based on established and open standards; see Principle 3 “The information modules of the IoT system are built in a horizontal overarching level and specific vertical levels”.

·   The EU Open Data Directive (formerly PSI Directive), which stipulates that data collected by public sector bodies shall be made available as far as possible.

·   The value of the information arises when the information is used.

·   In line with DIGG’s “Grundläggande principer för digital samverkan”, Principle 3 “Open up”, 6 “Ensure that information and data are transferable” and 13 “Take a holistic approach to information management”.

·   Contributes to Principle M7 “A common architecture framework exists and is used for all co-managed digital functions”, M11 “All data that can be shared should be shared as openly as possible in standardised formats”, and M12 “A digital infrastructure enables information exchange within the public sector and between the public and private sectors” in SALAR’s “Utveckling i en digital tid”.

·   The procuring organisation needs to have a clear picture of which information, services and data and how th make it available and how this will be done. Open data is one of the channels through which information can be made available.

·   The procuring organisation needs to identify its own competencies related to the acquisition and management of an IoT system. If competency is high, the procurer can have a solution that is flexible and may require less documentation, while lower competency may result in higher documentation requirements.

·   The procurer needs to ensure that users of information, services and data have access to support and documentation in order to use the information, services and data effectively.

·   Agreements with suppliers and the chosen architecture need to be linked so that operating and management costs can be managed efficiently.