IoT requirements catalogue
This page documents relevant requirements to set for IoT. The Arkitekturgemenskapen network’s guidelines for requirements can be found here: Requirements
The requirements catalogue is designed to be a guideline and support for how an IoT system can be procured, specifying what aspects a procurer needs to consider and manage. The focus is on asking a potential supplier questions, which can then be evaluated. Typically, a requirement contributes to one or more principles. Consequently, a potential supplier’s proposed solutions can be evaluated based on how they contribute to the various principles.
NOTE: The requirements below CANNOT be set directly in a procurement. Prior to a procurement, they need to be reformulated and adapted to the needs and objectives of that particular procurement. This includes e.g. formulating what SHALL requirements the procurer needs to set in their procurement. General IT requirements, or those that differ significantly between the procurer’s organisations, are not described in the IoT requirements catalogue, and need to be supplemented by the procurer. See more in the section “Areas not covered by the requirements catalogue as they are considered general IT knowledge”.
Examples of how the requirements catalogue can be converted into procurement requirements.
How to read the IoT requirements catalogue
A requirement can be considered an aspect that needs to be assessed in a specific IoT system. There is therefore a question (requirement formulation) intended to gain knowledge about how the solution is designed.
For most of the requirements, there is a clarification of the requirement, e.g. why it has been set, why it is important, or another description that a procurer may need to consider.
There is also “Suggestions for evaluation”, where the working group has listed what areas it considers important to evaluate for the respective requirement. A procurer may have other evaluation aspects that need to be added.
What principles a requirement contributes to.
Areas not covered by the requirements catalogue as they are considered general IT knowledge
Maintenance, support, monitoring and operation of IT systems
Information security management systems
General IT requirements which may differ significantly between procurer organisations
Documentation
There are some description requirements to clarify some IoT-specific areas.
Source code management
Life cycle management
Requirements management
Testing
However, there is a description requirement under IoT-1 related to this.
Logging / Observability
Description of colour coding for requirements:
White background – The requirement is fully completed and reviewed. The requirements are aligned with principles
Green background – The requirement is more or less fully formulated; review can be started
Yellow background – The requirement is well formulated; needs to be checked and internally reviewed
Red background – Working group material that is not finished or ready for any form of review
Requirement no. | Requirement formulation | Clarification of requirement | Suggestions for evaluation | Requirement areas / Work material | Contribution to principles |
KIOT-001 | The supplier should describe how the information set, information flow and information model in the IoT system is managed, configured, maintained, made available and gives an overview to the procurer. |
| Evaluate based on: · The quality of the overview provided by the documentation · How well maintenance and management of the documentation is described · How well tools or methods for gaining an overview of how e.g. a value was obtained are described |
| Principle 4 “Processing and enrichment of information” |
KIOT-002 | The supplier should describe how information can be processed and enriched at all or multiple levels of the IoT system. | The ability to enrich and process information is key in an IoT system. The enrichment and processing capabilities needed are very much dependent on the applications that will use the information. | Evaluate based on e.g.: · Capabilities for statistical analysis of data, e.g. what statistical packages are offered. · Ability to use external processing solutions (e.g. a web service or other programming language) for the IoT system. · Ability to combine data from different sources. · Evaluate based on anomaly detection capabilities. · Machine learning capabilities for handling aggregated time series, e.g. forecasting future metrics. · Capabilities for transforming data between different data models. · Ability to perform filtering and aggregation of data streams in order to make data available at different frequencies (second, 1 minutes, 15 minutes, 1 hour or another time period) directly on the streamed data. · Enriching collected data with metadata and master data from other data sources directly on the streamed data. · What is included in the supplier’s solution, and what are add-ons. |
| Principle 4 “Processing and enrichment of information” |
KIOT-003 | The supplier should describe how configuration and administration of modules for processing and enrichment can be carried out, e.g. change in transformation of data models, change in anomaly detection, etc. |
| Evaluate based on: · The ability to perform the actions easily in a web interface (NoCode/LowCode) by operations/maintenance personnel, without installing or modifying in the operating environment, and without the help of the supplier’s developers. · Assess the usability of the solution proposal. |
| Principle 4 “Processing and enrichment of information” |
KIOT-004 | The supplier should describe how configuration and administration of modules for control and orchestration and enrichment can be carried out, e.g. setting of rules, threshold levels, new/modified flows. |
| Evaluate based on: · The ability to perform the actions easily in a web interface (NoCode/LowCode) by operations/maintenance personnel, without installing or modifying in the operating environment, and without the help of the supplier’s developers. · Assess the usability of the solution proposal. |
| Principle 9 “The IoT system enables the management and orchestration of event-driven architecture” |
KIOT-005 | The supplier should demonstrate how event-driven and stored data in the IoT system can result in new events and/or activities. | The ability to react to information is key in an IoT system. Which capabilities to react to information are needed are very much dependent on the applications that will use the information. This is sometimes referred to as a rules engine. Such rules engines can be structured in different ways. | Evaluate based on e.g.: · Ability to create rules within the IoT system. · Ability and degree of configuration to create rules. · Ability to use AI or machine learning to create rules. |
| Principle 4 “Processing and enrichment of information” Principle 9 “The IoT system enables the management and orchestration of event-driven architecture” |
KIOT-006 | The supplier should describe what affects performance and capacity, and how scaling affects it within the IoT system. | In addition to this description requirement, the procurer should consider setting a number of SHALL requirements related to performance, based on the requirements of the application. These requirements may concern e.g.: · Number of physical IoT devices or virtual IoT devices, and how this number affects the performance in the rest of the IoT system. · Response times in data processing and enrichment. · Response times in storage. · Storage capacity. · Throughput of data. | Evaluate based on e.g.: · How complete a picture the supplier gives of what affects performance, capacity and scaling. · How complete a picture the supplier gives of what measures can be taken to increase the capacity of the IoT system without introducing additional hardware. · The strength of the commitments regarding performance, capacity and scalability the supplier makes in their responses. · What performance and capacity parameters the IoT system offers for measurement and monitoring, both internally and to external monitoring systems. · Evaluate based on scalability versus cost. |
| Principle 1 “The IoT system allows modules to be changed independently of each other” Principle 4 “Processing and enrichment of information” Principle 5 “The IoT system supports the storage of data in different ways based on the nature of the information and its usage needs” Principle 6 “The IoT system is capable of meeting a defined level of risk and impact” Principle 7 “The IoT system supports digital management of physical IoT devices and their connection to the IoT system.” Principle 9 “The IoT system enables the management and orchestration of event-driven architecture” Principle 10 “The IoT system’s information, services and data are accessible to applications and users” |
KIOT-006 | The supplier should describe the cost impact of the different scaling scenarios. | The procurer should describe some scenarios for current/future capacity needs of the IoT system. The supplier should estimate these, which can then be included in the evaluation. | Evaluate based on: · Cost estimates for the different scenarios. |
| Principle 1 “The IoT system allows modules to be changed independently of each other” Principle 4 “Processing and enrichment of information” Principle 5 “The IoT system supports the storage of data in different ways based on the nature of the information and its usage needs” Principle 7 “The IoT system supports digital management of physical IoT devices and their connection to the IoT system.” Principle 9 “The IoT system enables the management and orchestration of event-driven architecture” Principle 10 “The IoT system’s information, services and data are accessible to applications and users” |
KIOT-007 | The supplier should demonstrate how context awareness is created and maintained within the IoT system. |
| How it can be evaluated: · How comprehensive the description is. · How well it meets Principle 4 and Principle 2. |
| Principle 4 “Processing and enrichment of information” Principle 2 “Data, information and context awareness of the IoT system are preserved during module and system changes” |
KIOT-008 | The supplier should describe the version management process for the IoT system’s architecture as a whole, and for its constituent modules and interfaces. | Why the requirement is important: The IoT system will need to grow and change organically over time. It is therefore important that the following points are addressed during procurement of the IoT system: · Backward compatibility between modules · Version management of modules, e.g. upgrading of database systems · Version management of interfaces/standards for data transfer · Version management of the architecture as a whole The procurer may need to reformulate the requirement depending on who decides over the architecture. | How it can be evaluated: · Backward compatibility between modules · Version management of modules, e.g. upgrading of database systems · Version management of interfaces/standards for data transfer · Version management of the architecture as a whole. |
| Principle 1 “The IoT system allows modules to be changed independently of each other” |
KIOT-009 | The supplier should provide an architectural description of the IoT system, including its modular structure and the function of each module |
| How it can be evaluated: · Evaluate the solution based on how well functionally defined the modules are. · Evaluate the architectural description provided by the supplier e.g. based on the relevant parts of Annex A of DIN SPEC 91357 (which parts have to be specified in the procurement documents). |
| Principle 1 “The IoT system allows modules to be changed independently of each other” |
KIOT-010 | The supplier should describe how a test and acceptance environment can be established for the IoT system and its physical IoT devices. |
| How it can be evaluated: · Evaluate based on how complete the description is. · Based on how easy it is for a developer to test data flows. · Based on how easy it is to evaluate and test new sensors. |
| Principle 1 “The IoT system allows modules to be changed independently of each other” |
KIOT-011 | The supplier should demonstrate how the interfaces and data models of all modules in the IoT system can be based on established standards. |
| How it can be evaluated: · Evaluate the solution based the level of standardisation in the data formats used for transfer between modules. |
| Principle 1 “The IoT system allows modules to be changed independently of each other” Principle 3 “The information modules of the IoT system are built on standards in a horizontal overarching level and specific vertical levels” |
KIOT-012 | The supplier should demonstrate how each module of the IoT system complies with the information security measures contained in sections 4.1, 4.2 and 4.3 of the ENISA Baseline Security Recommendations for IoT or the like. | Why the requirement is important: Information security needs to be included by design in the IoT system. Compliance with ENISA information security measures is a good way to achieve an appropriate level of security for the application. In most organisations, the IoT system will involve multiple parties, e.g. operational organisations, management organisations, network systems. It is therefore essential that the client adequately manages responsibility issues between modules. The procurer may consider using the following material as a guideline for assessing relevant information security measures: · Swedish Civil Contingencies Agency’s “Vägledning för grundläggande kryptering” [Guide for basic encryption] · Swedish Civil Contingencies Agency’s Vägledning för fysisk informationssäkerhet i it-utrymmen [Guide for physical information security in IT spaces] · Swedish Local Fibre Alliance’s “Robust och Säker IoT” [Robust and secure IoT] · SALAR’s “Klassa för IoT” [IoT classroom] | How it can be evaluated: · Evaluate the supplier’s response based on what responsibility it takes for maintaining information security measures throughout the lifecycle of each module. · The procurer should consider breaking down and evaluating the supplier’s response in parts, based on ENISA’s breakdown or based on modules. · The procurer should consider evaluating how the supplier can adapt the IoT system to existing modules and capabilities in the procurer’s IT environment, e.g. for authentication and authorisation. · Evaluate the supplier’s response in terms of how well they define responsibilities between different actors in the IoT system. · How structured the presented IoT security approach is. · How accepted cybersecurity methodology is applied and referenced. · How all phases of the product lifecycle are covered. · How IT security is tested and verified in a relevant way, e.g. via penetration tests. · The supplier performs a self-assessment based on ENISA’s GAP analysis IoT Security Standards Gap Analysis |
| Principle 6 “The IoT system is capable of meeting a defined level of risk and impact” |
KIOT-013 | Supplier should demonstrate how the different modules of the IoT system can be integrated in the procurer’s authentication and authorisation system. (Description of existing solution provided by the procurer) | The procurer needs to describe which requirements actually need to be ordered. These requirements are very specific to the respective organisation. |
|
| Principle 6 “The IoT system is capable of meeting a defined level of risk and impact” |
KIOT-015 | IF there are processes around physical IoT devices that a supplier should manage: Supplier should describe the process for installation, replacement, calibration, service or maintenance (e.g. battery replacement) of physical IoT devices as needed. |
| Evaluate based on how the solution: · How the supplier describes preventive or reactive activities. · How each process is assessed as affecting availability in the data flow relative to information security around availability. |
| This requirements belongs to the “HOW” question, i.e. stratPAK, rather than RefARK. |
KIOT-014 | The supplier should describe how data can be stored |
| Evaluate based on how the solution: · Handles data that is time series based. · Meets the organisation’s information security, regulatory and policy requirements. · Is able to save unstructured and structured data, images, video, etc. · Enables flexibility in where and how data can be stored, e.g. in cloud, on-premises, data lake, database, or similar. · Can handle large/enormous data sets, based on performance and costs. · How information can be stored in different storage spaces based on e.g. information security classification. · Evaluate costs based on import, storage, access and export/migration |
| Principle 5 “The IoT system supports the storage of data in different ways based on the nature of the information and its usage needs” |
KIOT-016 | The supplier should describe how stored data can be processed and handled. | Description of the requirement: This requirement mainly refers to the processing of historical data that is done for some kind of archival purpose. | Evaluate based on how the solution: · Makes it possible to comply with retention policies, to be able to purge data after a specific period of time. E.g. a monthly automatic process that reduces second measurements to minute values, or manually delete measurements that are more than 2 years old. · Is able to move data between different storage media/spaces/data lakes to achieve the most efficient storage location depending on e.g. information security level, format, age, use and storage cost. · Is able to store all incoming data for a predefined time, e.g. 10 minutes or 30 days. · Is 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. · Is able to comply with GDPR requirements in relation to information on what is stored about a person and, where applicable, the right to be forgotten, i.e. the ability to search for and erase information. |
| Principle 5 “The IoT system supports the storage of data in different ways based on the nature of the information and its usage needs” Principle 4 “Processing and enrichment of information” |
KIOT-017 | The supplier should describe how data can be migrated to and from the storage module. | Description of the requirement: The procuring authority will most likely need to transfer data between storage modules during the life of the information. It is therefore important to have a clear picture of the costs involved in switching to another storage module at the beginning of the contract. | Evaluate based on: · Cost and capabilities of bringing information into the storage solution, both transactions from sensors and mass loading of existing information · Cost of having information stored · Cost and capabilities of exporting information in standardised formats. |
| Principle 1 “The IoT system allows modules to be changed independently of each other” Principle 5 “The IoT system supports the storage of data in different ways based on the nature of the information and its usage needs” |
KIOT-018 | The supplier should describe how data, information and context awareness can be fully and in detail imported into and exported from the modules of the IoT system. | Description of the requirement: The procuring authority will most likely need to transfer data between IoT systems during the life of the information. It is therefore important to have a clear picture of how data can be migrated between IoT systems at the beginning of the contract. | Evaluate based on: · What information models and ontologies the data can be exported as. The more standardised the format (i.e. ISO or open standards), the better. · Place a strong focus on context awareness. At present (2020), the working group believes it may be difficult to achieve this in the near future. · IF RELEVANT: How import from e.g. the procurer’s existing IoT systems (based on attached description) can be done. · Based on how the complete information set can be imported to/exported from the modules of the IoT system · How well the supplier describes the process, and how clear the cost picture for this is. · How complete the description around export of data, information and context awareness is, and what commitments the supplier makes in this respect. |
| Principle 2 “Data, information and context awareness of the IoT system are preserved during module and system changes” Principle 3 “The information modules of the IoT system are built on standards in a horizontal overarching level and specific vertical levels” |
KIOT-019 | The supplier should describe the information models and information exchange models within the IoT system, including how they are based on established and/or open standards. | Description of the requirement: · The information described by the supplier will most likely be considered a trade secret. It is therefore important to clarify to the supplier that the information will be treated as such. | Evaluate based on: · Are there defined code lists that translate/describe information sets? Do the code lists follow any kind of standard? · Is there an ontology describing information models and information exchange models that includes code lists? · How context awareness is structured and described · Are SI units used, and are they defined in the information model? · Is there supporting documentation describing the information set? · Are business objects defined and how are they related? · What established or open standards are described? · Ensure that ownership or usage rights to all of the above information belongs to the procurer at the end of the contract. |
| Principle 2 “Data, information and context awareness of the IoT system are preserved during module and system changes” Principle 3 “The information modules of the IoT system are built on standards in a horizontal overarching level and specific vertical levels” |
KIOT-020 | The supplier should describe how it is ensured that the procurer has full ownership and usage rights to all data, metadata, context awareness, and information models, both during and after the contract period. |
| Evaluate based on: · How does the supplier describe the procurer’s ownership and usage rights to all specified information? · How helpful the supplier is in assisting the procurer in migrating data, metadata, context awareness and information models to a new supplier. |
| Principle 2 “Data, information and context awareness of the IoT system are preserved during module and system changes” Principle 3 “The information modules of the IoT system are built on standards in a horizontal overarching level and specific vertical levels” |
KIOT-021 | The supplier should describe how information, data and services from the IoT system, both event-driven information and historical data, can be made available to applications and users via standardised interfaces (APIs). | This requirement needs to be adapted to the specific needs and IT environment of each organisation so that the IoT system procured is tailored to the procurer’s organisation. Description of the requirement: · The procurer needs to define how the information will be made available e.g. for other applications, open data, APIs, standardised data formats, etc. · The procurer needs to define in what formats data SHALL and/or SHOULD be made available. · The procurer is the owner of the information, and needs to ensure their access to the information. | Evaluate based on e.g. (and then based on the procurer organisation’s conditions and the solutions currently in place and clearly described in the procurement documents): · What interfaces (APIs/files e.g. csv) the IoT system can make available. · Which standards, established and/or open, that the IoT system can make available as standards, and how well they cover these. E.g. ETSI-NGSI-LD, W3C Web Of Things. [The procurer should add the standards and specifications they need here]. · How well the supplier describes version management and the backward compatibility of interfaces (APIs). · How well it meets the organisation's information security, regulatory and policy requirements (these should be described in the procurement documents). · That the supplier describes the amount of work involved in customising an interface (API/files). |
| Principle 10 “The IoT system’s information, services and data are accessible to applications and users” Principle 2 “Data, information and context awareness of the IoT system are preserved during module and system changes” |
KIOT-022 | The supplier should describe the service, support and documentation that the supplier offers for the IoT system. |
| Evaluate based on: · The detail level of the documentation of interfaces (APIs/files) the supplier makes available. Do not forget the metadata of the information made available in APIs/files. · Documentation is openly available. Documentation that is not openly available is rated lower. · What support and usage assistance the supplier offers. |
| Principle 10 “The IoT system’s information, services and data are accessible to applications and users” |
KIOT-023 | The supplier should describe the solution patterns available in the IoT system for access to information, data and services. |
| Evaluate based on: (based on what solutions are currently in place at the procurer organisation) · What solution pattern possibilities are offered. · Data subscription possibilities (Pub/Sub). · Capabilities for retrieving current and historical data with the same kind of interface (API). · Solution pattern related to actuator activation. · How well the supplier describes the reference architecture of the solution. |
| Principle 10 “The IoT system’s information, services and data are accessible to applications and users” |
KIOT-024 | The supplier should demonstrate how different vertical (domain-specific) information models (ontologies) are linked to the overall horizontal information model. |
| Evaluate based on: · How dynamic and adaptable the information models are, e.g. to handle SI units, descriptions of context awareness, carry information about function, product, and location. · How well the information model(s) are described. · Which specified information model standards are indicated, e.g. SOSA, oneM2M, SAREF. · What level of interoperability the standards provide (technical [e.g. REST] → syntactic [e.g. JSON, XML] → semantic [e.g. ontology] interoperability) · How clear the breakdown between the vertical and horizontal levels is. |
| Principle 3 “The information modules of the IoT system are built on standards in a horizontal overarching level and specific vertical levels” |
KIOT-025 | The supplier should explain how an application using the IoT system can have an information model tailored to its specific needs. |
| Evaluate based on: (for evaluation purposes, it is useful for the procurer to attach a description of specific solutions that may need to be adapted) · What standardised information models, included in the IoT system, exist for applications. · What adaptations the supplier can make to an application, and how complex it appears. |
| Principle 3 “The information modules of the IoT system are built on standards in a horizontal overarching level and specific vertical levels” Principle 4 “The IoT system enables the processing and enrichment of information [in different ways]” |
KIOT-026 | The supplier should describe how the IoT system can support the updating and configuration of physical IoT devices. Definitions: · Update (e.g. software update, e.g. firmware) · Configuration (e.g. how often the sensor delivers values) | A procurer may consider splitting this requirement into one requirement for configuration and one for updating if this serves a procurement function. | Evaluate based on: · How the solution supports automatic updating and configuration of larger groups of or individual IoT devices. · How updating and configuration can be done centrally on one or a small number of interfaces (GUI or function/API) within the IoT system. · Assess the usability of the solution proposal. · How updating and configuration can be done without physically visiting the IoT device (e.g. OTA Over-The-Air). · How configurations of IoT devices are preserved when updating. |
| Principle 7 “The IoT system supports digital management of physical IoT devices and their connection to the IoT system.” |
KIOT-027 | The supplier should describe how the IoT system can provision and deactivate physical IoT devices. Definitions: · Provisioning – the process of how a physical IoT device is set up in the IoT system. · Deactivation – e.g. stop listening to the IoT device or remove the virtual IoT device from the IoT system. |
| Evaluate based on: · The supplier's description of how one or more physical IoT devices can be provisioned or deactivated, e.g. when hundreds of sensors are to be included in the IoT system. · Assess the usability of the solution proposal. · Possibilities for batch management of physical IoT devices. |
| Principle 7 “The IoT system supports digital management of physical IoT devices and their connection to the IoT system.” |
KIOT-028 | The supplier should describe how a physical IoT device can be replaced, but still be connected to the same virtual IoT device. |
| Evaluate based on: · The supplier’s description of what solution patterns exist, to accomplish this in different ways. |
| Principle 7 “The IoT system supports digital management of physical IoT devices and their connection to the IoT system.” Principle 8 “The IoT system supports the management of virtual IoT devices and their linking to physical devices” |
KIOT-029 | The supplier should describe how the virtual IoT device can be modified to take in values from another physical IoT device. |
| Evaluate based on: · The supplier’s description of what solution patterns exist, to accomplish this in different ways. |
| Principle 7 “The IoT system supports digital management of physical IoT devices and their connection to the IoT system.” Principle 8 “The IoT system supports the management of virtual IoT devices and their linking to physical devices” |
KIOT-030 | The supplier should describe how physical IoT devices handled in the IoT system are represented and described in some kind of list. |
| Evaluate based on: · How the list of physical IoT devices is updated automatically · What information a list will contain, e.g. configuration data, identifier (name/number), make, model, capabilities, power supply, IP or other classification, which decoder to use, what connectivity it uses. · Whether the device information in the IoT system is accessible via a GUI and also via APIs. |
| Principle 7 “The IoT system supports digital management of physical IoT devices and their connection to the IoT system.” |
KIOT-031 | The supplier should describe how organisational ownership and management of physical IoT devices can be documented in a structured and clear way and made available to the procurer. |
| How it can be evaluated: · The procurer should describe in the procurement documents how the management of physical IoT devices is done within the procurer’s organisation, and evaluate how well the supplier’s description meets it. |
| Principle 7 “The IoT system supports the management of physical IoT devices and their connection to the IoT system” |
KIOT-032 | The supplier should describe how physical IoT devices can be monitored in the IoT system. | The procurer needs to define how monitoring should be done, in their own existing systems/infrastructure or in the supplier’s system. | How it can be evaluated: · How well the supplier’s solution fits with existing infrastructure. · How results of monitoring can be visualised to users, e.g. diagrams, maps. |
| Principle 7 “The IoT system supports the management of physical IoT devices and their connection to the IoT system” |
KIOT-033 | The supplier should describe which connectivity technologies can be used for connecting IoT devices in the IoT system, and under what conditions. Definition of connectivity technology: · E.g. LoraWan, NB-IoT, Wifi, 4G, 5G, 6G, etc. |
| Evaluate based on: · Which connectivity technologies can be used individually or simultaneously to connect to the IoT system. · Which connectivity technologies are included in the supplier’s solution and which are optional or require customisation. · The completeness of the description of the process for connecting additional connectivity technologies. · The capabilities for both IPv4 and IPv6 for communication at the network layer and with equivalent functionality. |
| Principle 7 “The IoT system supports digital management of physical IoT devices and their connection to the IoT system.” Principle 1 “The IoT system allows modules to be changed independently of each other” |
KIOT-034 | For each connectivity technology, the supplier should describe the physical constraints on the number, distance, density, bandwidth, range, latency, etc. of physical IoT devices. · The supplier provides solution proposals based on intended applications. | Physical IoT device REQUIREMENTS – Where the procurer owns and maintains the IoT devices. | Evaluate based on: · How well the supplier describes how the physical conditions/constraints of the connectivity technology. · The solution proposal put forth by the supplier based on a description of the intended applications, attached by the procurer. |
| Principle 6 “The IoT system is capable of meeting a defined level of risk and impact” Principle 7 “The IoT system supports digital management of physical IoT devices and their connection to the IoT system.” |
KIOT-035 | The supplier should describe the life cycle management of the IoT system and its components. | The requirement is intended to evaluate the supplier's ability to be a long-term partner to the procurer. | Evaluate based on: · The strength of the commitments the supplier makes about when new releases or functionality will be added to the IoT system, and how these will be made available to the procurer. · How completely the supplier describes all the modules in the IoT system, and how these are developed or decommissioned. |
| Principle 1 “The IoT system allows modules to be changed independently of each other” This requirement may belong more to HOW in StratPAK |
KIOT-036 | The supplier should describe how virtual IoT devices follow the information models of the IoT system. |
| Evaluate based on: (the procurer should adapt the requirements below to the IT environment) · How well the description follows PRINCIPLE 3: The information modules of the IoT system are built on standards in a horizontal overarching level and specific vertical levels. · What information models virtual devices can adopt, e.g. proprietary or standardised. · To what extent can the same IoT system handle multiple concurrent information models? |
| Principle 3 “The information modules of the IoT system are built on standards in a horizontal overarching level and specific vertical levels” Principle 8 “The IoT system supports the management of virtual IoT devices and their linking to physical devices” |
KIOT-037 | The supplier should describe how a virtual IoT device can be created and used without being connected to any physical IoT device (i.e. simulated virtual IoT device). | A virtual IoT device can retrieve data from sources other than physical IoT devices connected to the IoT system. For example, a virtual IoT device can retrieve information from: · Internet services, e.g. weather information from the Swedish Meteorological and Hydrological Institute (SMHI) · Computed values from several different physical or virtual IoT devices. For example, a virtual IoT device can deliver the average value of several temperature sensors. · Other systems, e.g. SCADA systems or EDGE devices. | Evaluate based on: · The completeness of the supplier's description of the capabilities to create simulated virtual IoT devices. · How well the solution pattern fits into the procurer’s overall solution. |
| Principle 8 “The IoT system supports the management of virtual IoT devices and their linking to physical devices” |
KIOT-038 | The supplier should describe how [the administrator of] the IoT system can create, configure, review and delete virtual IoT devices. |
| Evaluate based on: · How complete and visual the administration interface is. · The ability to see which applications are using a virtual IoT device. |
| Principle 8 “The IoT system supports the management of virtual IoT devices and their linking to physical devices” |
KIOT-039 | The supplier should describe how a virtual IoT device can be used to access both event-driven information and historical data. |
| Evaluate based on: · The completeness of the supplier’s description of the capabilities, and how useful it is. |
| Principle 8 “The IoT system supports the management of virtual IoT devices and their linking to physical devices” |
KIOT-040 | The supplier should describe what is included in IoT system maintenance during the contract period. | The question is important to create transparency between supplier and procurer. It is about understanding what is included in the supplier’s commitment in relation to management and maintenance. | Evaluate based on: · The completeness of the description. · The strength of the supplier’s commitment in terms of what is included during the contract period |
| HOW REQUIREMENTS → StratPAK |
KIOT-041 | The supplier should describe how management and orchestration can be configured, monitored and modified. |
| Evaluate based on: · The completeness of the description. · How information flows can be monitored. · The quality of the overview provided by the tools · The flexibility of the solution in terms of modifying management and orchestration, e.g. scheduling and scripting. · Possibilities for deviation and anomaly detection in data traffic. · Ability to prioritise incoming messages according to configured order of priority. · Ability to control messages according to data content, i.e. message content, device information, information classification and other categories. · Possibility of functionality to create traceability (verification chain) of how a message has been processed in the IoT system. |
| Principle 9 “The IoT system enables the management and orchestration of event-driven architecture” |
KIOT-042 | The supplier should describe the management and orchestration solution pattern provided by the solution. | Examples of solution patterns include COAP, MQTT, LWM2M (Lightweight M2M), APIs, event-controlled queue management. The procurer should consider as a minimum that: The IoT system SHALL, as a minimum, support the following data protocols for the application/presentation layer: REST and MQTT. | Evaluate based on: · The completeness of the description |
| Principle 9 “The IoT system enables the management and orchestration of event-driven architecture” |
KIOT-043 | The supplier should describe capabilities for visualising data from physical and virtual IoT devices in diagrams, tables, maps and the like. |
| Evaluate based on:
|
| Principle 7 “The IoT system supports digital management of physical IoT devices and their connection to the IoT system.” Principle 8 “The IoT system supports the management of virtual IoT devices and their linking to physical devices” Principle 9 “The IoT system enables the management and orchestration of event-driven architecture” |
KIOT-044 | The supplier should describe how the IoT system can ensure that sent sensordata arrives complete and unchanged to the reciever. | For critical applications or applications where e.g. is important with continuous time series or the accumulated collected values are of great importance, you do not want to lose incoming data, for example in the event of malfunctions or if the connection is broken. It is therefore important that there are functions to ensure that data is stored and can be accessed and processed afterwards when the IoT system works normally again. As the number of sensors has grown, situations may arise where the load on the IoT system at certain times exceeds the system's ability to receive and process incoming data. Then it is important that the IoT system can, for example, queue up incoming data and process it in an appropriate order. Ideally, you then also want the opportunity to set priority so that data for the most critical applications are prioritized. | Evaluate based on:
|
| Principle 6 “The IoT system is capable of meeting a defined level of risk and impact” Principle 7 “The IoT system supports digital management of physical IoT devices and their connection to the IoT system.” Principle 9 “The IoT system enables the management and orchestration of event-driven architecture” Principle 10 “The IoT system’s information, services and data are accessible to applications and users” |
KIOT-45 | The supplier should describe how the IoT system and its IoT devices can be configured/controlled to send only the necessary data when needed. |
| Evaluate based on:
|
| Principle 6 “The IoT system is capable of meeting a defined level of risk and impact” Principle 7 “The IoT system supports digital management of physical IoT devices and their connection to the IoT system.” Principle 9 “The IoT system enables the management and orchestration of event-driven architecture” |