Requirements
Up one level
Welcome to the IoT-A Unified Requirements list !
Preamble
Requirements in IoT-A are mainly targeted at supporting and
validating the work on the Architectural Reference Model (ARM). While
requirement work within the project tries to follow requirement best
practices (by using as much as possible Volere methodology, by using input
from both potential end-users and developers), producing and exploiting
requirements on a Reference Architecture (and Model) level is somewhat
different than for a concrete system (for which the state of the art
methodology is largely targeted). This results in a number of specifics
that the reader should keep in mind:
- Prioritization of requirements for the ARM is largely inapplicable – while it is largely considered best practice in concrete system specification.
- Formulation (description field) of requirements expressed by external or internal stakeholder may sometimes refer directly to the ARM, but in most cases they apply to a concrete system. In that latter case, they express characteristics on the system that the ARM should enable to specify.
- Mapping to perspective/views/functional groups and components is done on a lowest common denominator basis – e.g. it indicates which aspect is definitely impacted by a given requirement, but the reader should keep in mind that in certain (concrete system) specific cases, other components may need to be considered.
How to use this list?
The requirements are presented as a dynamic table, with the following fields for each requirement:
- ID: Each requirement is uniquely identified by a three-digit number: UNI.klm. The numbering scheme indicates where requirements come from (e.g. all requirements with klm <200 are issued from stakeholders, those with klm > 200 are either based on state of the art or about our understanding of the IoT domain, with the 600 range being devoted to security and 700 devoted to management) and is not continuous due to discards/merges.
- Requirement Type: Type of requirement among the three categories Functional Requirements / Non-Functional Requirements / Design Constraints.
- Category: general keywords applicable to the requirement to ease their grouping regardless of ARM specificities (e.g. allows to tag all requirements that impact privacy regardless of their origin)
- Description: The description is the intent of the requirement. It is a statement about what the system has to fulfil according to the rationale.
- Rationale: The rationale is the reason behind the requirement’s existence. It explains why the requirement is important and how it contributes to the system’s purpose. It typically refers to direct stakeholder input for stakeholder-originated requirements, or an explanation/reference for internally-originated requirements.
- View: One or several ARM Views to which the requirement is related.
- Functionality Group: One or several Functionality Groups in the functional decomposition of the ARM to which the requirement is related.
- Functional Component: One or several Functional Components in the functional decomposition of the ARM to which the requirement is related. These functional components are part of the groups listed in the functionality-group field.
- Domain Model: One or several Domain Model entities to which the requirement is related.
- Perspective: One or several Perspectives to which a requirement is related.
Filtering
The table is highly dynamic, with the possibility to perform a global search, as well as filter for each column. For example, one can perform a global search on the word 'communication' (search all columns box), or filter all requirements categorized with the tag privacy (Category column filter), or those which apply to the Management Functionality Group (Functionality Group column filter).
I'm missing an important requirement in the list...
We have put a lot of care in building this list based on many different sources. If you think an important aspect is missing, please contact us.
For details on the requirement gathering process and complete list with more characteristics (e.g. business originating scenarios, fit criterions, etc), please refer to the most recent WP6 requirement deliverable.
| UNI ID | Requirement Type | Category | Description | Rationale | View | Perspective | Functionality Group | Functional Component | Domain Model | ||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| UNI.001 | Non-functional Requirements | Privacy | A system built using the ARM shall provide a means to allow people to use Internet of Things services anonymously | "Citizens want to protect their private data" | Functional | Security and Privacy | Security | Identity Management | User, Service, Resource, Device | ||||
| UNI.002 | Non-functional Requirements | Privacy, Usage | Users have control how their data is exposed to other users | "Citizens want to protect their private data" | Functional | Security and Privacy | Security | Authorisation | Human User, Service, Resource | ||||
| UNI.003 | Non-functional Requirements | Self-description, Semantics | A system built using the ARM shall enable the provision and exchange of semantics between services in order to support the design of new applications | "I would like a way to create and exchange semantics between objects in order to design new applications" | (none) | Evolution and Interoperability | (none specific) | (none specific) | Service, Resource | ||||
| UNI.004 | Non-functional Requirements | Self-description, Semantics | A system built using the ARM shall enable the semantic description of physical entities | "I would like a way to create and exchange semantics between objects in order to design new applications" | Information | (none) | (none specific) | (none specific) | (none) | ||||
| UNI.005 | Functional Requirements | Autonomicity, Data handling & Communication | A system built using the ARM shall support event-based, periodic, and/or autonomous communication | "The remote monitoring device gathers patient measurements, data and or events. Data may be communicated each time the device gathers the data, accumulated measurements may be communicated periodically (e.g., hourly, daily), or data may be delivered upon request or upon certain events" | Functional | (none) | IoT Service | IoT Service | (none) | ||||
| UNI.008 | Non-functional Requirements | Interoperability | A system built using the ARM shall be able to run applications and services in an interoperable manner | "The problem is to provide a framework, a set of scenarios where these applications could be developed in harmony, in an interoperable way and in a way that responses to the real needs of organization and people" | (none) | Performance and Scalabiltiy | (none specific) | (none specific) | Service | ||||
| UNI.010 | Non-functional Requirements | Autonomicity | A system built using the ARM shall enable autonomous goal-driven (task-driven) collaboration between devices or services | "I would expect that the traffic lights collaborate for a goal" - Smart objects should collaborate in order to realize a common goal (such as traffic lights in order to reduce traffic or pollution). | (none) | Evolution and Interoperability | (none specific) | (none spedific) | Device, Service | ||||
| UNI.012 | Non-functional Requirements | Radio-awareness, Data handling & communication, Resilience | A system built using the ARM shall be able to handle interference between IoT devices (avoidance and detection) | "In order to achieve a reliable eHealth service the system must be interference-free" | (none) | Evolution and Interoperability | Communication | Hop to Hop Communication | Service, Device | ||||
| UNI.014 | Functional Requirements | Autonomicity | A system built using the ARM shall support devices to activate themselves into a collaboration | "The remote monitoring device is prepared for use and communication by the action of the patient or clinician. This may involve physically attaching or placing the device, registering the device, setting up the communications channels to M2M application entities, setting up the communications capabilities of the device and providing for secure communications." | Deployment | (none) | Management | Configuration | Device, Service, Resource | ||||
| UNI.015 | Functional Requirements | Resource control | A system built using the RA shall be able to remotely control and configure devices | "The remote monitoring device may be configured by via the M2M network by the M2M application entities. The configuration capability could span simple parametric changes, such as, reporting rates, event or alarm trigger levels, and dosing levels to downloading and securely restarting new operating software" | Deployment, Operation | (none) | Management | Configuration, Member, State | Device, Service, Resource | ||||
| UNI.016 | Functional Requirements | Discovery & lookup, Geolocation | A system built using the ARM shall support physical entity location tracking (geo spatial and/or logical location) | "High value assets need to be tracked in order to avoid theft and also to know where they are currently located" | Information, Functional | (none) | Virtual Entity | VE Resolution, VE & IoT Service Monitoring, VE Service | Augmented Entity, Resource, Service | ||||
| UNI.018 | Functional Requirements | Data handling & communication | A system built using the ARM shall support data processing (filtering, aggregation/fusion, ...) on different IoT-system levels (for instance device level) | "The remote monitoring device gathers patient measurements, data and or events. Data may be communicated each time the device gathers the data, accumulated measurements may be communicated periodically (e.g., hourly, daily), or data may be delivered upon request or upon certain events" | Functional | (none) | IoT Service | IoT Service | Service | ||||
| UNI.019 | Functional Requirements | Data handling & communication, Usage | A system built using the ARM shall support user-initiated communication | "Providers can initiate communication with the patients health monitoring device for a number of reasons. Examples of this include a provider querying the device for a reading or for configuring such a device" | Functional | (none) | IoT Service | IoT Service | (none) | ||||
| UNI.020 | Functional Requirements | Radio-awareness | A system built using the ARM shall support real-time monitoring of radio usage of devices and gateways | "The application knows the current radio transmission activity of the M2M device" | Functional | (none) | Communication | Hop to Hop Communication | Device | ||||
| UNI.021 | Functional Requirements | Radio-awareness, Usage, Energy-awareness | The user shall be able to control the radio activity of the system | "The application can control the radio transmission" | Functional | (none) | Communication, Management | Hop to Hop Communication, Configuration | Device | ||||
| UNI.022 | Functional Requirements | Security, Usage, Access Control | A system built using the ARM shall provide end users with secure access to resources | "Patients are able to initiate communication to the providers Electronic Medical Record (EMR) or health database application using the secure messaging tool for a variety of purposes. Examples include providing manually gathered information on existing self-monitoring and/or chronic care regiments." | Functional | (none) | IoT Service, Security | IoT Service, Key Exchange & Management | (none) | ||||
| UNI.023 | Non-functional Requirements | Interoperability, Enterprise Integration | A system built using the ARM shall provide access to external information sources, e.g. health databases | "Patients are able to initiate communication to the providers Electronic Medical Record (EMR) or health database application using the secure messaging tool for a variety of purposes. Examples include providing manually gathered information on existing self-monitoring and/or chronic care regiments." | (none) | Evolution and Interoperability | (none specific) | (none specific) | Resource, Storage | ||||
| UNI.026 | Functional Requirements | QoS, Data handling and communication | A system built using the ARM shall support time-critical message handling and delivery on a second time scale. | "In case of emergency the Remote Monitoring Device has to send or receive time critical messages" | Functional | Performance and Scalabiltiy | Communication | (none specific) | (none) | ||||
| UNI.027 | Functional Requirements | QoS | A system built using the ARM shall support prioritization of services | "In case of time-sensitive services the system needs to assure that important services are prioritized" | Functional | Performance and Scalabiltiy | (none specific) | (none specific) | (none specific) | ||||
| UNI.028 | Functional Requirements | QoS, Data handling and communication | A system built using the ARM shall provide a message-prioritization mechanism | "Not every message has the same priority" | Functional | Performance and Scalabiltiy | Communication | (none specific) | (none specific) | ||||
| UNI.030 | Functional Requirements | Discovery & lookup, Naming, Addressing | A system built using the ARM shall provide a resolution infrastructure for naming, addressing and assignment of virtual entities and services | "A system may be provided which is operable to determine a routing node for a data object. The system can comprise an identifier generator operable to generate an identifier for the data object on the basis of data content thereof, and a lookup engine operable to compare the identifier for the data object to a routing table to determine a routing node for the data element." | Functional | (none) | Virtual Entity, IoT Service | VE Resolution, IoT Service Resolution | VE, Service, Resource | ||||
| UNI.031 | Functional Requirements | Service composition & programmability | A system built using the ARM shall enable centralized or decentralized automated activities (control loops) | "Today, due to sub-optimal processes, a lot of time and money is wasted. This situation could be improved a lot by tracking all the items/things, providing context data on them at any time and location, allowing for automated evaluation of the collected data and reacting immediately on a dangerous situation to protect against the break down of items." | Functional | (none) | IoT Business Process Management | Business Process Modeling, Business Process Execution | Service | ||||
| UNI.032 | Functional Requirements | Service composition & programmability, Usage | A system built using the ARM shall enable the planning of automated tasks | "Today, due to sub-optimal processes, a lot of time and money is wasted. This situation could be improved a lot by tracking all the items/things, providing context data on them at any time and location, allowing for automated evaluation of the collected data and reacting immediately on a dangerous situation to protect against the break down of items." | Functional | (none) | IoT Business Process Management | Business Process Modeling, Business Process Execution | Service | ||||
| UNI.036 | Functional Requirements | Self-description, Usage, Semantics | A system built using the ARM shall enable the retrieval of the self-description of things | "My wish is to retrieve the capacity of a thing. Thus, I can plan a change maintenance of all my bulbs if they can say when they should be changed" | Functional | (none) | Virtual Entitty | VE Resolution | Service, Resource | ||||
| UNI.040 | Non-functional Requirements | Security, Resilience | A system built using the ARM shall provide ways to ensure security and resilience | "Road users and energy providers want to avoid shortages/ blackouts" | (none) | Availability and Resilience | (none specific) | (none specific) | (none specific) | ||||
| UNI.041 | Functional Requirements | Data handling & communication | A system built using the ARM shall provide historical information about the physical entity | "A method for clarification whether the Cold/Hot Chain has been violated or not is required. To be able to do this, the continuous context information (e.g., temperature) of the things needs to be collected. This is for example of major importance to avoid any damage to the pharmaceutics during the transport and storage process." | Information, Functional | (none) | IoT Service | IoT Service | Physical Entity | ||||
| UNI.042 | Non-functional Requirements | Data handling & communication | A system built using the ARM shall enable both user and device to exchange information about their state | "Both the M2M server and the M2M device must be able to provide information about the current state" | (none) | Evolution and Interoperability | (none specific) | (none specific) | User, Device, Service, Resource | ||||
| UNI.043 | Functional Requirements | Service composition & programmability | A system built using the ARM shall enable the composition of entity-related services | "The costs for complex logistics and healthcare processes need to be kept on a low level. A modular setup of the applications and services is one important ingredient to achieve this. Therefore it should be very easy to integrate things together with their atomic services into other services, and it should be easy for things to use services provided by others." | Functional | (none) | Service Organization | Service Composition, Service Orchestration | Service | ||||
| UNI.047 | Non-functional Requirements | Interoperability | The system must ensure interoperability between objects or between applications | "As an example, CCTV system could inform traffic management of the length of the waiting queue at a crossroad. Having smart traffic lights receiving such input from the CCTV system could, could help changing the schedule of green/red light to optimize the traffic." | (none) | Evolution and Interoperability | Security | Key Exchange & Mangement | (none specific) | ||||
| UNI.048 | Functional Requirements | Interoperability, Discovery & lookup, Naming, Addressing | A system built using the ARM shall provide interoperable naming and addressing | "IoT-A will play a role in terms of providing a kind of novel resolution infrastructure. We need to understand how best IoT could be served by scheme regarding the naming of objects, the addressing and assigning problems." | Functional | Evolution and Interoperability | Communication | Hop to Hop Communication, Network Communication | (none) | ||||
| UNI.050 | Non-functional Requirements | Discovery & lookup, Geolocation | A system built using the ARM shall support mobility of the physical entity | "The use of M2M Devices for monitoring health related information is not confined to the residence of the patient." | (none) | Availability and Resilience | (none specific) | (none specific) | Augmented Entity | ||||
| UNI.058 | Non-functional Requirements | QoS, Availability, Resilience | The system shall provide high availability | "Communication blackouts are not accepted from client side and particularly if they are paying for premium services" | (none) | Availability and Resilience | (none specific) | (none specific) | (none specific) | ||||
| UNI.060 | Non-functional Requirements | QoS, Usage | The system shall support different SLA | "Communication blackouts are not accepted from client side and particularly if they are paying for premium services" | (none) | Availability and Resilience | (none specific) | (none specific) | Service | ||||
| UNI.062 | Design constraints | Security, Trust, Data handling & communication Availability, Integrity | A system built using the ARM shall provide trusted and secure communication and information management | "A method for clarification whether the Cold/Hot Chain has been violated or not is required. To be able to do this, the detailed context information (e.g., temperature) of the things, which have been collected in some database need to be easily made available. This is for example of major importance to avoid any damage to the pharmaceutics during the transport and storage process." | (none) | Security and Privacy | (none specific) | (none specific) | (none) | ||||
| UNI.064 | Non-functional Requirements | Availability, Resilience, Reliability | A system built using the ARM shall provide availability through resilience | "Security, why? Simply because the IoT - I am sure you will demonstrate it - is a kind of critical information infrastructure which means that if ever for whatever reason there is a failure somewhere on the IoT the impact will be so high that it would be a social loss, like if we do not have more electricity." | (none) | Security and Privacy, Availability and Resilience | (none specific) | (none specific) | Service | ||||
| UNI.065 | Non-functional Requirements | QoS, Reliability | A system built using the ARM shall provide reliable services | "In order to accommodate certain scenario, support of a certain degree of reliability might be necessary" | (none) | Availability and Resilience | (none specific) | (none specific) | Service | ||||
| UNI.066 | Functional Requirements | Security, Integrity | A system built using the ARM shall provide integrity validation of virtual entities, devices, resources, and services | "In certain life-critical applications the device may be required to perform a secure start-up procedure that includes integrity checking." | (none) | Performance and Scalabiltiy | Management | Member, State | Virtual Entity, Service, Device, Resource | ||||
| UNI.067 | Functional Requirements | Security, Access Control | A system built using the ARM shall provide different access permissions to information | "Sensitive data of patients must be kept secure in order to assure trust between the patients and to allow access to certain people" | Functional | (none) | Security | Authorisation | Resource | ||||
| UNI.070 | Functional Requirements | Self-description, Semantics | A system built using the ARM shall provide interoperability through the use of semantics | "I would like a way to create and exchange semantics between objects in order to design new applications" | Information | (none) | (none specific) | (none specific) | Service | ||||
| UNI.071 | Design constraints | Data handling & communication, Semantics, Interoperability | A system built using the ARM shall provide standardized and semantic communication between services | "Standard communications between objects, from a communication channel point of view but also from a semantic point of view. (Standardization of object semantic is somehow similar to the standardization of MIB (Management Information Base) of telecommunication equipments)." | (none) | Evolution and Interoperability | (none specific) | (none specific) | Service | ||||
| UNI.073 | Functional Requirements | Semantics, Usage | A system built using the ARM shall allow the semantic description of physical entities and services by a user | "I would like a way to create and exchange semantics between objects in order to design new applications" | Information | (none) | (none specific) | (none specific) | Virtual Entity, Service, Resource | ||||
| UNI.087 | Functional Requirements | Service composition & programmability | A system built using the ARM shall support service lifecycle management |
"A service is something that originates at a certain time for accomplishing goals…that lives for a certain reason, may endure for a time, and may or may not be retired" [Bell, Michael (2008). "Introduction to Service-Oriented Modeling". Service-Oriented Modeling: Service Analysis, Design, and Architecture. Wiley & Sons] |
Operation | (none) | (none specific) | (none specific) | Service | ||||
| UNI.089 | Non-functional Requirements | N/A | A system built using the ARM shall support reliable time synchronization | "Services which depend on a precise time need a guarantee that the devices they are communicating to have the right time." | (none) | Performance and Scalabiltiy | (none specific) | (none specific) | (none) | ||||
| UNI.092 | Non-functional Requirements | Usage | Remote services shall be accessible by human users | "The mobile phone of the consumer can and should be used for interacting with product centric services" | (none) | Availability and Resilience | (none specific) | (none specific) | Service | ||||
| UNI.093 | Non-functional Requirements | Interoperability, Extensibility | A system built using the ARM shall be extensible for future technologies. | "The reference architecture shall provide an integral approach that combines legacy aspects as well as an imaginating vision on the Internet of Things." | (none) | Evolution and Interoperability | (none specific) | (none specific) | (none) | ||||
| UNI.094 | Non-functional Requirements | N/A | The Architectural Reference Model shall support any IoT business scenario. | "The reference architecture shall provide the building blocks in a creative way coming from a business perspective." | (none) | Evolution and Interoperability | (none specific) | (none specific) | (none) | ||||
| UNI.095 | Design constraints | Data handling & communication, Addressing | A system built using the ARM shall include an interface to IP communication protocols. | "The reference architecture shall consider that we have gateways to IP everywhere, so we must have a global addressing system with protocol and so on. That would be an evolution of IPv6. Or we need an integration package for existing addressing systems." | Functional | (none) | Virtual Entity, IoT Service, Communication | VE Resolution, IoT Service Resolution, Network Communication | Service, Resource, Device, Virtual Entity | ||||
| UNI.096 | Functional Requirements | Autonomicity, Self-Configuration | A system built using the ARM shall support the autonomous and dynamic selection of protocols without human intervention. | "Future systems implementing the reference architecture shall allow for a dynamic selection of protocols and layers without any human intervention." | Functional | Evolution and Interoperability | Communication, Service Organization | End-to-End Communication, Service Composition, Service Orchestration | Device, Service | ||||
| UNI.097 | Functional Requirements | Data handling & communication | A system built using the ARM shall support information (data) lifecycle management. | "Deal with the lifecycle of information (how to distinguish, if information (tag) is temporary not available or not valid any more?)" | Information | (none) | (none specific) | (none specific) | (none) | ||||
| UNI.098 | Functional Requirements | Semantics, Geolocation | A system built using the ARM shall have a semantic understanding of distance and location. | "It is necessary to make the system know what defines a distance." - this is necessary to discover location-based services | Information | (none) | IoT Service, Virtual Entity | IoT Service Resolution, VE Resolution | Service, Virtual Entity | ||||
| UNI.099 | Non-functional Requirements | N/A | A system built using the ARM shall guarantee correctness of resolutions. | "When searching for a certain object you need an implemented system that actually gives you the correct result." | Functional | (none) | IoT Service, Virtual Entity | IoT Service Resolution, VE Resolution | (none) | ||||
| UNI.100 | Functional Requirements | Resource control | A system built using the ARM should include means to wake-up sleepy devices. | "We must look out also for some way to wake up sleepy communications in order to manage energy consume." | Functional | (none) | Communication | Hop to Hop Communication | (none) | ||||
| UNI.101 | Functional Requirements | Energy-awareness, Resource Control | A system built using the ARM shall include means to manage the energy consumption of devices. | "We must look out for a highly energy efficient system." | Functional | Performance and Scalabiltiy | Communication, Management | Hop to Hop Communication, Configuration | (none) | ||||
| UNI.102 | Non-functional Requirements | Interoperability, Enterprise Integration, Extensibility | A system built using the ARM shall take into account external computing resources, e.g. 'the cloud'. | "Maybe there should be some part of processing information in the cloud." | (none) | Performance and Scalabiltiy | (none specific) | (none specific) | (none) | ||||
| UNI.211 | Functional Requirement | Enterprise Integration, Usage | The process-modeling notation has to be extensible in terms of the definition of new symbols, the specification of new syntax, the definition of serialisation and execution semantics. | The reuse of an existing process-modeling notation allows to focus the effort on the IoT-extension. | Information | (none) | IoT Business Process Management | Business Process Modeling | (none) | ||||
| UNI.212 | Functional Requirement | Enterprise Integration | The process-modeling notation has to be executable. | The projects task 2.2 and 2.3 should closly work together and represent a hand in hand solution. | Functional | (none) | IoT Business Process Management | Business Process Modeling | (none) | ||||
| UNI.213 | Non-functional Requirement | Enterprise Integration, Usage | The process modeling notation shall be able to describe IoT-specific aspects, as, for instance, availability. |
The standard established process notations cannot cope with IoT specific aspects, but in order to address IoT aware processes, one needs to be able to describe them appropriately. [Sonja Meyer, Klaus Sperner, Carsten Magerkurth, Jacques Pasquier (2011): Towards Modeling Real-World Aware Business Processes. Web of Things 2011. San Francisco, USA, June 6, 2011.] |
Information | (none) | IoT Business Process Management | Business Process Modeling | (none) | ||||
| UNI.214 | Non-functional Requirement | Enterprise Integration, Usage | The specification of the system's process-modeling notation shall include a graphical representation. | A graphical process notation offers a symbolism to easily model and document business processes. | Information | (none) | IoT Business Process Management | Business Process Modeling | (none) | ||||
| UNI.215 | Non-functional Requirement | Enterprise Integration | The used process-modeling notation shall adhere to a standard. | A common standard maximizes the potential application of industrial stakeholders. | Information | (none) | IoT Business Process Management | Business Process Modeling | (none) | ||||
| UNI.229 | Non-functional Requirement | Extensibility | The process-execution functional component shall be "easily and fastly" extendable. | The development should focus on the IoT related extension. | Information | (none) | IoT Business Process Management | Business Process Execution | Service | ||||
| UNI.232 | Functional Requirement | Interoperability | The process-execution engine shall support the integration with a complex-event-processing (CEP) component. | One WP central process execution engine including the CEP enables a bigger research contribution. | Functional | Availability and Resilience | IoT Business Process Management, Service Organization | Business Process Execution, Service Orchestration | (none) | ||||
| UNI.233 | Design Constraint | Data Handling & communication | Mobile entities shall be able to provide events to the platform | Many physical entities such as mobile phones, products in a retail store, etc. are mobile and IoT-A must be able to detect changes related to those entities | (none) | Availability and Resilience | (none specific) | (none specific) | Active Digital Artefact | ||||
| UNI.234 | Non-functional Requirement | Data Handling & communication | Events shall be processed on a set of distributed nodes | A distributed architecture provides more flexibility in the way events are processed, saves energy and allows minimal functionality if there is no network connectivity | (none) | Performance and Scalability | Service Organization | Service Composition, Service Orchestration | (none) | ||||
| UNI.235 | Functional Requirement | QoS, Data Handling and communication | Processing of events shall take quality of informaton (QoI) into account | In IoT the quality of information stemming from events is often questionable. | Functional | (none) | Service Organization | Service Composition, Service Orchestration | (none) | ||||
| UNI.236 | Functional Requirement | QoS, Data Handling and communication, Usage | A system built using the ARM shall offer services for the retrieval of quality of information related to virtual entities. | Different devices provide information with varying quality. An application may have certain quality requirements. | Functional | (none) | IoT Service | IoT Service | Service | ||||
| UNI.237 | Functional Requirement | QoS, Data Handling and communication | A system built using the ARM shall offer data types for describing the quality of information related to virtual entities. | Different devices provide information with varying quality. An application may have certain quality requirements. | Information | (none) | (none specific) | (none specific) | Resource | ||||
| UNI.239 | Functional Requirement | Resource Control | A system built using the ARM shall provide a Storage Resource with a shared cache, in which an observable phenomenon is stored | Due to resources could not be online all the time it could be necessary to incorporate an intermediate shared memory in order to store this information, so it could be accessed by services using these information. | Functional | (none) | IoT Service | IoT Service | Service | ||||
| UNI.240 | Functional Requirement | Interoperability, Self-Description | A system built using the ARM shall provide unified interfaces to access and query the resource/entity meta data | This will enable WP4 discovery and identification and also reasoning mechanisms to access the required descriptions | Functional | (none) | Virtual Entity, IoT Service | VE Service, IoT Service | Service | ||||
| UNI.241 | Functional Requirement | Interoperability, Resource Control | A system built using the ARM shall provide unified interfaces to access and query the observation and measurement data emerging from resources | This will enable integration of IoT data into business layer and high-level applications. | Functional | (none) | IoT Service | IoT Service | Service | ||||
| UNI.244 | Functional Requirement | Service composition & programmability | The orchestration engine shall interpret service descriptions |
Service orchestration needs to be done based on IOPE information provided in service descriptions. [Bell, Michael. 2008. Service-Oriented Modeling. Chichester: John Wiley & Sons.] |
Functional | (none) | Service Organization | Service Composition, Service Orchestration | Service | ||||
| UNI.245 | Functional Requirement | Service composition & programmability | The service organization shall support creation of new applications | Composite services allow added value services based on simple services | Functional | (none) | Service Organization | Service Composition, Service Orchestration | Service | ||||
| UNI.247 | Functional Requirement | Service composition & programmability | The service organization shall support flexible composition |
Services involved in compositions can fail and need to be replaced by some serving equal needs. [Kephart, J. O., & Chess, D. M. (2003). The vision of autonomic computing. Computer, 36(1), 41-50.] |
Functional | (none) | Service Organization | Service Composition, Service Orchestration | Service | ||||
| UNI.251 | Functional Requirement | Service composition & programmability, Usage | The service organization shall provide a feedback to the user who sent a composition request |
The service user needs to be informed whether or not the composition request has succeded or failed due to uncertainty of service availability. |
Functional | (none) | Service Organization | Service Composition, Service Orchestration | Service | ||||
| UNI.252 | Non-functional Requirement | Usage | The service organization shall provide feedback within a reasonable amount of time. |
A time out must be set for request/response loops. For requests entered by human users a limit of 10 seconds could be reasonable. After that an error is assumed. |
Operation | (none) | Service Organization | Service Composition, Service Orchestration | Service | ||||
| UNI.253 | Functional Requirement | Service composition & programmability, Usage | The orchestration engines shall support setting preferences for selecting services involved in composition | Users can have the possibility to prefer one service over another for any reason | Functional | (none) | Service Organization | Service Composition, Service Orchestration | Service | ||||
| UNI.301 | Functional Requirement | Data handling & communication | A system built using the ARM shall support one to one communication between devices (e.g. unicast messages). | In order to support direct collaboration between devices (e.g. choreography), one needs to provide direct one to one communication. This is refered to as local gossip in [S. S. Kulkarni, “TDMA Services for Sensor Networks,” Proc. 24th Int’l. Conf. Distrib. Comp. Sys. Wksps. , Mar. 2004, pp. 604–09] | Functional | (none) | Communication | Network Communication | Devices (Sensors, Tags, Actuators) | ||||
| UNI.302 | Functional Requirement | Data handling & communication | A system built using the ARM shall support communication between groups of devices (e.g. multicast messages). |
In order to support collaboration between groups of devices (e.g. choreography), one needs to provide group to group communication. [Tian He; Stankovic, J.A.; Chenyang Lu; Abdelzaher, T., "SPEED: a stateless protocol for real-time communication in sensor networks," Distributed Computing Systems, 2003. Proceedings. 23rd International Conference on , vol., no., pp.46,55, 19-22 May 2003] |
Functional | (none) | Communication | Network Communication | Devices (Sensors, Tags, Actuators) | ||||
| UNI.303 | Functional Requirement | Data handling & communication | A system built using the ARM shall support reverse multicast messages. | Typical IoT sensor scenarios like having a group of terminals to send data (possibly aggregated at some intermediate point) to a single terminal located within the same or a different network domain, should be covered. This is refered to as convergecast in [S. S. Kulkarni, “TDMA Services for Sensor Networks,” Proc. 24th Int’l. Conf. Distrib. Comp. Sys. Wksps. , Mar. 2004, pp. 604–09] | Functional | (none) | Communication | Network Communication | Devices (Sensors, Tags, Actuators) | ||||
| UNI.304 | Functional Requirement | Data handling & communication | A system built using the ARM shall support anycast messages. |
This is required by scenarios such as when a single terminal sends data to a destination terminal which is selected based on a set of attributes specified by the sender rather than on id or location. [Tian He; Stankovic, J.A.; Chenyang Lu; Abdelzaher, T., "SPEED: a stateless protocol for real-time communication in sensor networks," Distributed Computing Systems, 2003. Proceedings. 23rd International Conference on , vol., no., pp.46,55, 19-22 May 2003] |
Functional | (none) | Communication | Network Communication | Devices (Sensors, Tags, Actuators) | ||||
| UNI.305 | Functional Requirement | Data handling & communication | A system built using the ARM shall support one to many / one to all communication (e.g. broadcast messages). |
In certain IoT scenarios (e.g. sensor networks), a single node (the sender) sends data to all nodes of a network, for example for configuration purposes. [S. S. Kulkarni, “TDMA Services for Sensor Networks,” Proc. 24th Int’l. Conf. Distrib. Comp. Sys. Wksps., Mar. 2004, pp. 604–09] |
Functional | (none) | Communication | Hop to Hop Communication | Devices (Sensors, Tags, Actuators) | ||||
| UNI.306 | Functional Requirement | Data handling & communication | Data-memory-constrained devices must be able to participate in communication. This means that a system built using the ARM shall support communication stacks with small data footprint. |
In some IoT scenarios, constrained devices with in particular a very small amount of data memory needs to be able to join communication. |
Functional | (none) | Communication | (none specific) | Devices (Sensors, Tags, Actuators) | ||||
| UNI.307 | Functional Requirement | Data handling & communication | Network-stack-constrained devices must be able to participate in communication.This means that a system built using the ARM shall support constrained communication stacks. |
In some IoT scenarios, constrained devices with in particular simplified network stacks may need to engage in communication. |
Functional | (none) | Communication | (none specific) | Devices (Sensors, Tags, Actuators) | ||||
| UNI.308 | Functional Requirement | Data handling & communication, Resilience | A system built using the ARM shall support communication over Low-power and Lossy networks. |
In some IoT scenarios, IoT-devices need to communicate across an non-reliable networks, like Low-power and Lossy networks. There is a wide scope of application areas for LLNs, including industrial monitoring, building automation (HVAC,lighting, access control,fire), connected homes, healthcare, environmental monitoring, urban sensor networks (e.g. Smart Grid), asset tracking. |
Functional | (none) | Communication | Hop to Hop Communication, Network Communication | Devices (Sensors, Tags, Actuators) | ||||
| UNI.309 | Functional Requirement | Data handling & communication, Energy-awareness | A system built using the ARM shall support power-less devices (in particular the latter may be able to participate in communication). |
In some IoT scenarios, power-less devices may need to engage in communication, e.g. by harvesting energy before triggering constrained communication. [Aman Kansal, Jason Hsu, Sadaf Zahedi, and Mani B. Srivastava. 2007. Power management in energy harvesting sensor networks. ACM Trans. Embed. Comput. Syst. 6, 4, Article 32 (September 2007).] |
Functional | (none) | Communication | Hop to Hop Communication, Network Communication | Devices (Sensors, Tags, Actuators) | ||||
| UNI.310 | Functional Requirement | Data handling & communication, Energy-awareness | A system built using the ARM shall support power-constrained devices (in particular the latter may be able to participate in communication). |
Communication must be open also for devices with constrainend power, like battery-powered devices. |
Functional | (none) | Communication | Hop to Hop Communication, Network Communication | Devices (Sensors, Tags, Actuators) | ||||
| UNI.311 | Functional Requirement | Data handling & communication | A system built using the ARM shall support stateless communication methods. |
In some IoT scenarios, stateless-devices must be able to participate in communication. [Tian He; Stankovic, J.A.; Chenyang Lu; Abdelzaher, T., "SPEED: a stateless protocol for real-time communication in sensor networks," Distributed Computing Systems, 2003. Proceedings. 23rd International Conference on , vol., no., pp.46,55, 19-22 May 2003] |
Functional | (none) | Communication | (none specific) | Devices (Sensors, Tags, Actuators) | ||||
| UNI.312 | Functional Requirement | Data handling & communication, Interoperability | A system built using the ARM shall use/support common-addressing-schemes such as IPv6. |
The usage of IPv6 is common practice in IoT systems. [N. Kushalnagar, G. Montenegro, C. Schumacher, IPv6 Over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals, IETF RFC 4919, August 2007.] |
Functional | Evolution and Interoperability | Communication | Network Communication | Devices (Sensors, Tags, Actuators) | ||||
| UNI.313 | Functional Requirement | Data handling & communication, Interoperability | A system built using the ARM shall support mapping from different addressing schemes to IP v6 (Compatible-addressing-scheme support). | Communication with non-IPv6 networks must be possible (IPv4, others). | Functional | Evolution and Interoperability | Communication | Network Communication | Devices (Sensors, Tags, Actuators) | ||||
| UNI.314 | Functional Requirement | Data handling & communication | A system built using the ARM shall support identity-locator split, i.e. making the device's identity independent from its locator | Multi-homing and mobility induce that a network nodes's identity
(e.g. a device identity) should be distinguished from its network
locator (e.g. it's IP address). [IETF 79
proceedings] |
Functional | Evolution and Interoperability | Communication | Network Communication | Devices (Sensors, Tags, Actuators) | ||||
| UNI.315 | Functional Requirement | Data handling & communication | A system built using the ARM shall support routing over heterogenous networks. |
Device need to communicate across heterogenous networks. In particular IoT systems shall support communications between different types of networks (like constrained and unconstrained networks). |
Functional | (none) | Communication | Network Communication | Devices (Sensors, Tags, Actuators) | ||||
| UNI.318 | Functional Requirement | Data handling & communication | A system built using the ARM shall support sleepy devices, i.e. devices with periodic / non-permanent network access. |
Some IoT devices, in particular power-constrained nodes, may have only intermittent network access. |
Functional | (none) | Communication | Hop to Hop Communication, Network Communication | Devices (Sensors, Tags, Actuators) | ||||
| UNI.319 | Functional Requirement | Data handling & communication, Access control | A system built using the ARM shall support limiting network access to specific devices (e.g. devices may need to provide appropriate credentials before being granted the right to join a network). | For security reasons (rogue device joining an IoT system), safety reasons (liability) and accounting reasons, it may be necessary to control access to an IoT system. | Functional | Security and Privacy | Communication,Security, Management | Hop to Hop Communication, Autorisation, Member | Devices (Sensors, Tags, Actuators) | ||||
| UNI.320 | Functional Requirement | Data handling & communication | A system built using the ARM shall support multi-homing, i.e. devices connecting to more than one network and to dialing in with multiple ids and locators. | Devices with more than one network interface / connection should be able to communicate in several networks concurrently. | Functional | (none) | Communication | Network Communication | Devices (Sensors, Tags, Actuators) | ||||
| UNI.321 | Functional Requirement | Data handling & communication, Availability | Devices must be able to switch between different networks without losing connections (Network handover/handoff support). | To guaranty continuity of service, IoT devices may need to change between different networks without losing ongoing connections | Functional | Availability and Resilience | Communication | Network Communication | Devices (Sensors, Tags, Actuators) | ||||
| UNI.322 | Functional Requirement | Data handling & communication, Privacy | A system built using the ARM shall support anonymous communication between devices (Anonymity support). | In some cases, IoT devices may need to communicate without disclosing its identity | Functional | Security and Privacy | Security | Identity Management | Devices (Sensors, Tags, Actuators) | ||||
| UNI.324 | Functional Requirement | Data handling & communication, Availability | Devices must be able to switch between different networks when moving, e.g. roaming. (Mobility support) | To guaranty continuity of service, IoT devices may need to change between similar networks without losing ongoing connections | Functional | Availability and Resilience | Communication | Network Communication | Devices (Sensors, Tags, Actuators) | ||||
| UNI.326 | Functional Requirement | Data handling & communication, Interoperability | The system shall support interworking between different application protocols (what to communicate), for example through translation functionality in an IoT gateway. | Seamless communication between all kinds of applications,e.g. business, desktop and mobile applications, must be possible. | Functional | Evolution and Interoperability | Communication | End to End Communication | Devices (Sensors, Tags, Actuators) | ||||
| UNI.327 | Functional Requirement | Data handling & communication, Interoperability | The system shall support interworking between different networking protocols (how to communicate), for example through translation functionality in an IoT gateway. | To enable communications between constrained and unconstrained devices of an IoT system, adaptation between networking protocols may be required. | Functional | Evolution and Interoperability | Communication | Network Communication | Devices (Sensors, Tags, Actuators) | ||||
| UNI.328 | Functional Requirement | Data handling & communication | The system shall support network virtualisation, i.e. the usage of virtual overlay networks. | The usage of Virtual Private Networks (VPN) must also be possible in IoT systems. | Functional | (none) | Communication | Network Communication | Devices (Sensors, Tags, Actuators) | ||||
| UNI.401 | Functional Requirement | Discovery & lookup, Geolocation | Discovery and lookup services of the system shall allow locating physical entities based on geographical parameters |
This requirement is derived from SmartProducts (SP) requirement "A SmartProduct should be able to locate another SmartProduct in the same environment w.r.t. their environment" |
Functional | (none) | Virtual Entity | VE Resolution | Augmented Entity (Physical Entity +Virtual Entity) | ||||
| UNI.402 | Non-Functional Requirement | Self-description, Geolocation | A system built using the ARM shall provide geographical-location attributes for virtual entities |
Derived from SP requirement "A SmartProduct should be able to access the location information of other SmartProducts" |
Functional | (none) | Virtual Entity | VE Resolution | Virtual Entity | ||||
| UNI.403 | Functional Requirement | Self-description, Geolocation | A system built using the ARM shall support a standardized location model and location-information representation. |
Derived from SP requirement "Smart products shall support a standardized location model and location-information representation." |
Functional | (none) | Virtual Entity | VE Resolution | Virtual Entity | ||||
| UNI.404 | Functional Requirement | Self-description, Geolocation | A system built using the ARM shall support a hybrid location model, that is, it shall support symbolic coordinates as well as local and global geometric coordinates |
Derived from SP requirement "Smart products shall support a hybrid location model, that is, it shall support symbolic coordinates as well as local and global geometric coordinates" |
Functional | (none) | Virtual Entity | VE Resolution | Virtual Entity | ||||
| UNI.405 | Functional Requirement | Service composition and programmability, Extensibility, Geolocation | A system built using the ARM shall allow programmers to add new coordinate reference systems and shall support the transformation of coordinates among them |
Derived from SP requirement: The location model shall allow programmers to add new coordinate reference systems and shall support the transformation of coordinates among them |
Functional | (none) | Virtual Entity | (none) | Virtual Entity | ||||
| UNI.406 | Functional Requirement | Discovery & lookup, Geolocation | The discovery service of the system shall support the following location queries: position queries, nearest neighbour queries, navigational queries, and range queries |
Derived from SP requirement: "The location model shall support the following common location queries: position queries, nearest neighbour queries, navigational queries, and range querie" |
Functional | (none) | Virtual Entity | VE Resolution | Virtual Entity | ||||
| UNI.407 | Functional Requirement | Discovery & lookup , Security, Access Control | The look-up service of the system shall withold or grant information depending on context. Context includes application involved, requesting entity, and security permissions |
Derived from BRIDGE requirement: "A broad set of data from enterprise applications MAY be requested depending on context, industry, application, etc" |
Functional | Security and Privacy | Security | Authorisation | Augmented Entities (Physical Entity + Virtual Entity) | ||||
| UNI.408 | Functional Requirement | Self-description, Discovery & Lookup | The system's services shall indicate what information can be found by a discovery/look-up service |
Opting out of being found in a data search was indicated in the BRIDGE requirement list and also in the IoT-A Stakeholder Opinion Report. The BRIDGE requirement was "Data that companies are willing to provide to the Discovery Services are mainly URL addresses of databases / EPCIS repositories" |
Deployment | Security and Privacy | Virtual Entity | VE Resolution | Services | ||||
| UNI.409 | Functional Requirement | Data handling & communication | A system built using the ARM shall allow storage of VE changes, including structural changes (e.g. changes in the aggregation of multiple VEs constituting one overarching VE) |
This is a main functionality of the BRIDGE system which applies to RFID/assets tracked in the EPCGlobal framework [ BRIDGE deliverable: "High level design for Discovery Services".] |
Functional | (none) | Virtual Entity | VE Service | Virtual Entity | ||||
| UNI.410 | Functional Requirement | Security, Access Control | The storage of Digital Entity History information shall be restricted in who can delete and update it |
The integrity and trust in the history storage block depends on how "unaltered" it is. The BRIDGE project justifies the present use of the "history storage" component. They expressed it as "Discovery Service security policies may be set to restrict update and delete actions on DS records" |
Functional | Security and Privacy | Virtual Entity | VE Service | Virtual Entity | ||||
| UNI.411 | Functional Requirement | Security, Access Control | A system built using the ARM shall offer a unique identification of clients requesting data via the discovery/lookup services | BRIDGE mentioned that the unique client identification at the DS is required to control access to data stored on the DS (particularly EPC number and link). | Functional | Security and Privacy | Security | Authentication | Users (Human, Active Digital Artefact) | ||||
| UNI.412 | Functional Requirement | Security, Access Control | Data owners should be able to set access-control rights/ policies (set up by data owners) to their data stored on resources | This addresses privacy by putting the control in the hands of the data owners (or certain external groups) | Functional | Security and Privacy | Security | Authorisation | Users (Human, Active Digital Artefact) | ||||
| UNI.413 | Design Constraint | Security, Access Control, Privacy, Security Management | Access-control rights/ policies (set up by data owners) shall not be published publicly. | Access control policies themselves, if known, can give away information. | Deployment | Security and Privacy | (none) | (none) | Resource | ||||
| UNI.414 | Functional Requirement | Discovery & lookup, Self-description | A system built using the ARM shall enable the dynamic discovery of virtual entities and their services. This is to be done based on the specification of the service and the virtual enities. | Augmented entities are the core concept proposed for IoT and to enable applications that do not have to be a-priori configured for a fixed set of augmented entities, discovery at runtime must be possible. | Functional | (none) | Virtual Entity | VE resolution | Virtual Entity | ||||
| UNI.415 | Functional Requirement | Discovery & lookup, Geolocation | A system built using the ARM shall enable the dynamic discovery of virtual entities and their related services based on a geographical location | Geographic location is one of the most important aspects for finding relevant virtual entities. Spatial relations are of prime importance in the physical world. | Functional | (none) | Virtual Entity | VE resolution | Virtual Entity | ||||
| UNI.416 | Functional Requirement | Discovery & lookup | A system built using the ARM shall enable the lookup of service descriptions of specified services for a virtual entity with the VE identifier as key for the lookup | It is important to find the services related to a virtual entity that may provide information about the virtual entity, allow to actuate the virtual entity, or enable interaction with the virtual entity. | Functional | (none) | Virtual Entity | VE resolution | Virtual Entity | ||||
| UNI.417 | Functional Requirement | Discovery & lookup | A system built using the ARM shall enable the resolution of service identifiers to service locators | Due to the heterogeneity, dynamicity and mobility in the Internet of Things, the communication endpoint may change or different endpoints may be suitable for different applications. Therefore, services should be uniquely identified by a service identifier, but this identifier should not be used for locating the service, so a resolution step is necessary. | Functional | Evolution and Interoperability | IoT Service | IoT Service Resolution | Service | ||||
| UNI.418 | Functional Requirement | Discovery & lookup | A system built using the ARM shall be able to discover dynamic associations between virtual entities and service related to virtual entities | Due to the mobility of physical entities as well as devices whose resources are accessible through services, changing services may provide information, allow actuation or enable interaction with physical entities. In order to provide the currently relevant services for a corresponding virtual entity, the dynamic assoications must be discovered | Functional | (none) | Virtual Entity | VE & IoT Service monitoring | Augmented Entities (Physical Entity + Virtual Entity) | ||||
| UNI.419 | Functional Requirement | Discovery & lookup, Autonomicity | A system built using the ARM shall be able to track dynamic associations between a virtual entity and services related to the virtual entity. This needs to be done in order to determine whether they are still valid. | Due to the mobility of things, as well as devices whose resources are accessible through services, changing services may provide information, allow actuation, or enable interaction with things. In order to provide the currently relevant services for a thing, dynamic assoications must be tracked to determine whether they are still valid. | Functional | (none) | Virtual Entity | VE & IoT Service monitoring | Augmented Entities (Physical Entity + Virtual Entity) | ||||
| UNI.420 | Functional Requirement | Discovery & lookup, Autonomicity, Geolocation | A system built using the ARM shall be able to discover dynamic associations based on geographic location and other context information. | Mobility is one of the key reasons for changing associations. By monitoring both the location of physical entities and the service area of resources, dynamic associations can be discovered. Based on the proximity of the physical entity, the service area of the resource and the functionality provided by the resource, it can be determined whether the resource can provide any information about the physical entity or enable any actuation on the physical entity. If this is the case, an association between the virtual entity, which represents the physical entity in the system, and the service, which makes the functionality of the resource accessible, can be established. | Functional | (none) | Virtual Entity | VE & IoT Service monitoring | Augmented Entities (Physical Entity + Virtual Entity) | ||||
| UNI.421 | Functional Requirement | Discovery & lookup, Autonomicity, Geolocation | A system built using the ARM shall be able to track dynamic associations between a virtual entity and services based on geographic loaction to determine whether they are still valid. | Mobility is one of the key aspects for changing associations. By monitoring the location of physical entities, e.g., using location services, it can be determined when associations become invalid due to the geographic distance of physical entities and the service areas of resources and possibly other and possibly other aspects. | Functional | (none) | Virtual Entity | VE & IoT Service monitoring | Augmented Entities (Physical Entity + Virtual Entity) | ||||
| UNI.422 | Design Constraint | Discovery & lookup | A system built using the ARM shall enable the discovery and lookup of associations across multiple administrative domains. | The Internet of Things will consist of multiple administrative domains with different owners that generally manage their devices, resources, services virtual entities etc. independently. To develop its full potential interactions, including lookup and discovery, across domain boundaries must be possible. | (none) | Evolution and Interoperability | Virtual Entity | VE Resolution | Virtual Entity | ||||
| UNI.423 | Functional Requirement | Privacy | When performing discovery, resolution or lookup, the system must respect any aspect of privacy, including the possibility to retrieve information about or related to people by using (or subverting the use of) the Internet of Things. In addition some services should be accessible in an anonymous way, while others might require an explicit authentication or authorization of the user. | Privacy is a key aspect for the IoT. | Functional | (none) | IoT Services, Virtual Entity, Security | IoT Service Resolution, VE Resolution, Identity Management | Servicemboussar: was Services (Intergation & Interoperability Layer) ? | ||||
| UNI.424 | Functional Requirement | Privacy | A system built using the ARM shall provide privacy protection for users accessing information about physical entities or services | For acceptance of the Internet of Things privacy during usage must be guaranteed | Functional | Security and Privacy | Security | Identity Management | User, Service | ||||
| UNI.425 | Functional Requirement | Self-description | A system built using the ARM shall provide a service identifier, and the identifier shall use a service/resource description for retrieval. | The system must consider the description of a service/resource for the semantic indexing on which the search will be performed | Functional | (none) | IoT Service | IoT Service Resolution | Servicemboussar: was Services (Intergation & Interoperability Layer) | ||||
| UNI.426 | Functional Requirement | Discovery & lookup, Semantics | A system built using the ARM shall be able to accept and manage semantic queries from the user and return Resources/Services | Iot Service Resolution functional component has interfaces to enable the user make queries for the discovery,lookup and resolution functions. | Functional | (none) | IoT Service | IoT Service Resolution | Servicemboussar: was Services (Intergation & Interoperability Layer) | ||||
| UNI.427 | Functional Requirement | Discovery & lookup, Semantics | The Discovery Service in a local search is required to find service/resource based on (rough) semantic description | Users must be able to discover Services locally in their environment. This is because in many cases users a) might not be able to leverage infrastructure services b) leveraging the Infrastructure would be ineffective and c) context-awareness would be higher if information is derived from local network (e.g. in an underground garage, proximity might be measured with higher accuracy using network metrics respect to using A-GPS or cell-based localization). | Functional | (none) | IoT Service | IoT Service Resolution | Resourcemboussar: was Resources (Computational Element for PE Access) | ||||
| UNI.428 | Functional Requirement | Discovery & lookup | A system built using the ARM shall provide a service that obtains unique identifiers for associations between VE and the service. | Association between Ves and the services is one of the key parameters for the resolution functional component and association contains unique association ID for example to manage it (such as delete, insert) | Functional | (none) | Virtual Entity | VE Resolution | Virtual Entity | ||||
| UNI.429 | Functional Requirement | Discovery & lookup | The IoT resolution component shall provide a service to insert or update the operational specifications (i.e. type, description, locator) of a new IoT service into the data base that is used for discovery, lookup, and resolution. | In order for lookup and global discovery to work properly, a IoT service-resolution component must provide a way to insert and update the description of services that it will then use as a search basis. | Functional | (none) | IoT Service | IoT Service Resolution, IoT Service | Service | ||||
| UNI.432 | Functional Requirement | Discovery & lookup | A system built using the ARM shall provide a virtual identification system. | A universal identifier should be defined as standard ID in order to map it to the specific ID used in every type of system (TCP/IP, RFID, ...) | Functional | Evolution and Interoperability | Virtual Entity | VE Resolution | Augmented Entities (Physical Entity + Virtual Entity) | ||||
| UNI.501 | Non-functional Requirement | Security | A system built using the ARM shall make it difficult to spy on communicated messages. | The confidentiality of messages must be ensured. | (none) | Security & Privacy | Security | Key Exchange & Management, Authentication | Device Tag Physical entity Virtual entity Resource | ||||
| UNI.502 | Non-functional Requirement | Security | A system built using the ARM shall prevent a device (contactless card for example) from being activated without the consent of the owner. | The unsolicited scanning of people shall be avoided. A device is always owned by a person or an entity. For example, in a retail use case, the owner of an RFID tag can be a retailer and after the checkout the new owner should be the client. The aim is to avoid skimming attacks | (none) | Security & Privacy | Security | Authorisation | Device Tag User Physical entity Virtual Entity | ||||
| UNI.503 | Functional Requirement | Usage, Security, Integrity, Non-Repudiation, Privacy | A system built using the ARM shall make it be possible to change the owner of a device (tag for example). | A device is always owned by a person or an entity. For example, in a retail use case, the owner of an RFID tag can be a retailer and after the checkout the new owner should be the client. The aim is to avoid skimming attacks. Privacy preserving solutions in RFID require to share a secret key between tag and reader (or owner since in this case, the owner enters his key in the reader). It must be possible to change this key in tag and reader (and even in the databases where the data related to the device is stored) if the owner has changed. | (none) | Security & Privacy | Security | Authorisation, Authentication, Key Exchange & Management | Device Tag Physical entity Virtual entity Resource | ||||
| UNI.504 | Non-functional Requirement | Security, Privacy, Access Control | A system built using the ARM shall prevent tracking of the identifier of the device (ID of an RFID tag for example) by unauthorised entities. | The tracking of items and then people raise the problem of privacy. To preserve privacy, only the owner of the tag shall be able to read it. So, authoized persons are the owner and the persons who are authorized by the owner. The "unauthorized entities" are all the other people. | (none) | Security & Privacy | Security | Autorisation, Authentication, Key Exchange & Management | Device Tag User Physical entity Virtual Entity | ||||
| UNI.505 | Functional Requirement | Energy-awareness | A system built using the ARM shall support connecting devices able to do energy harvesting. | Maintain operation in environments where power supply is not possible. | Functional | (none) | Management, | Configuration, Performance, Member | Device | ||||
| UNI.506 | Design Constraint | Interoperability, Data handling & communication | A system built using the ARM shall support communication accross devices by aid of standardised communication interfaces. | Use of standard interfaces will enable take up of IOTA concept on the market | (none) | Evolution & Interoperability | Communication | Network Communication | Device | ||||
| UNI.507 | Non-functional Requirement | Security, Privacy, Data handling & communication | A system built using the ARM shall support data security & privacy at atomic level | Security in end-to-end communication does not address security issues pertaining to the device itself. | (none) | Security & Privacy | Security | Authorisation, Key Exchange & Management | Resource, Device | ||||
| UNI.508 | Non-functional Requirement | Data handling & communication | A system built using the ARM shall support intermittent and command-based communication with devices | Avoid traffic overhead | (none) | Evolution & Interoperability | (none specific) | (none specific) | (none) | ||||
| UNI.509 | Non-functional Requirement | Self-description | Each IoT device shall possess a universal ID, part of it read only and part of it read/write. | Enable object recognition and setup/configuration in the context of applications development | (none) | Evolution & Interoperability | (none specific) | (none specific) | Resource | ||||
| UNI.510 | Functional Requirement | Security | Atomic-level protocols must implement only functions related to data acquisition (e.g. DSP-level), crypto and security | Atomic-level protocols are the protocols realised to carry out a particular task related to device internal functions. E.g. how data are acquired from the environmnet. How they are encoded/encrypted for transportation of unreliable networks, etc. This requirements is needed to avoid overlap with user-level communication protocols. | Functional | (none) | (none specific) | (none specific) | Device | ||||
| UNI.511 | Non-functional Requirement | Energy-awareness, Availability, Autonomicity, Resilience | A system built using the ARM shall be scalable, that is, usable on very tight resources with potentially reduced features (e.g., the level of security may be different depending on the underlying hardware resources) | IoT faces many issues in that complex features have been to be made available on restrained devices (memory size, CPU speed, power consumption). For example, can an OS be run on something like an 8-bit CPU, 8 KB RAM, 64 KB flash platform? Or can use of symmetric crypto algorithms (e.g., AES) be run on resource-constraint platforms w/ AES co-processor functionality? | (none) | Performance and Scalability, Security and Privacy | (none specific) | (none specific) | Device, Resource | ||||
| UNI.512 | Non-functional Requirement | Energy-awareness, Autonomicity | An application shall share information about resource usage (for instance, when will the application need to transmit a message) with other functional layers. | IoT systems are often resource constrained, especially in terms of energy consumption. Optimum energy efficency can only be achieved by cross-functional-layer optimisation, which is dependent on application needs. | (none) | Performance and Scalability | (none specific) | (none specific) | Device, Resource | ||||
| UNI.601 | Non-functional Requirement | Security, Availability, Resilience | A system built using the ARM shall guarantee infrastructure availability | The services provided by the infrastructure should always be available, as their operation is critical to the operation of the Internet of Things. Users should thus be able to reach the infrastructure. The infrastructure services should be able to operate. | (none) | Availability and Resilience, (Security and Privacy) | IoT Service, Security | IoT Service Resolution, IoT Service | (none) | ||||
| UNI.602 | Non-functional Requirement | Privacy, Trust | The "infrastructure services" of a system built using the ARM (i.e. resolution services, security services, management services) shall be trustable | The services provided by such "infrastructure services" should be trustworthy. | (none) | Security and Privacy | IoT Service, Security, Management | IoT Service Resolution, VE Resolution, (none specific), (none specific) | User, Service | ||||
| UNI.603 | Functional Requirement | Integrity | The "infrastructure services" of a system built using the ARM (i.e. resolution services, security services, management services) shall comply with the infrastructure service design and operate accordingly | Such "infrastructure services" should operate properly according to their design. | Operation, (Deployment) | (none) | IoT Service, Security, Management | IoT Service Resolution, VE Resolution, (none specific), (none specific) | (none) | ||||
| UNI.604 | Non-functional Requirement | Security, Access control, Availability, Resilience | A service shall always be accessible to entitled users | Access to the service shall be regulated by access policies. Users entitled in access policies to envoke a given service must be able to actually envoke it. | (none) | Availability and Resilience, (Security and Privacy) | IoT Service, Security | IoT Service Resolution, IoT Service | Service | ||||
| UNI.605 | Non-functional Requirement | Privacy, Trust | A system built using the ARM shall support the reversing of the pseudonymization processes in order to guarantee mutual accountability | Some scenarios require Subjects to take responsibility for their actions. Some Services could be classified or critical for their provider and could require Users to take responsibility of their action. On the other hand Users might need providers to take responsibility for the Services they provide, because relying on such Services is critical for them. The IoT should support the reversing of the Pseudonymization processes. | (none) | Security and Privacy | IoT Service, Security | IoT Service, Identity Management | User, Service | ||||
| UNI.606 | Non-functional Requirement | Privacy, Non-repudiation | A system built using the ARM shall make the traceability of digital activities impossible | Subjects should not be able to track the digital activities of other subjects | (none) | Security and Privacy | IoT Service, Security | IoT Service Resolution, IoT Service, Identity Management, Authorization | User, Service | ||||
| UNI.607 | Functional Requirement | Privacy, Trust | A system built using the ARM shall provide communication confidentiality | The exchange of information between Subjects (Users and Services) should be understandable only for the intended recipients. This is a generic communication requirement because it can be achieved at different layers of the the stack. | Functional | (none) | IoT Service, Security | IoT Service, Key Exchange & Management | User, Service | ||||
| UNI.608 | Functional Requirement | Security, Integrity | A system built using the ARM shall support communication integrity | The messages exchanged between subjects must be delivered in a complete and coherent way. It can affect communications at different layers (MAC, NWK, TRA). | Functional | (none) | Communication, Security | (none specific), Key Exchange & Management | User, Service | ||||
| UNI.609 | Non-functional Requirement | Security, Integrity | A system built using the ARM shall ensure Data Freshness | The system should be protected from replay attacks (message replays at Service level, packet replay at network and link layer level). | (none) | Security and Privacy | Security | Key Exchange & Management | Device, Service | ||||
| UNI.610 | Non-functional Requirement | Security, Availability | A system built using the ARM shall provide IoT-Service availability | Services providing access to Resources must be reachable by the Users who might need to rely on them. This requirement has a specific IoT declination as the resources of many nodes will be constrained and specific ways to protect from DoS or exhaustion attacks will be needed. | (none) | Availability and Resilience, (Security and Privacy) | IoT Service, Security | IoT Service, Authentication, Authorization, Trust & Reputation | Service, Device | ||||
| UNI.611 | Non-functional Requirement | Security, Access control | A system built using the ARM shall support access control mechanisms | The control of User access to Resources must be supported and, where needed, regulated by policies. Anonymous interaction must be supported and group authorization should be supported. | (none) | Security and Privacy | IoT Service, Security | IoT Service, Authorisation, Identity Management | User, Service | ||||
| UNI.612 | Non-functional Requirement | Security, Privacy, Trust | A system built using the ARM shall support mutual subject authentication | Subjects (Users and Services) must be able to confirm the identity of other Subjects. | (none) | Security and Privacy | IoT Service, Security | IoT Service, Authentication, Identity Management | User, Service | ||||
| UNI.613 | Functional Requirement | Security, Trust | A system built using the ARM shall be able to meter service reputation | As there is a high chance of nodes being compromised due to their physical availability to malicious users, a secondary mechanism for establishing trust is needed. | Functional | (none) | IoT Service, Security | IoT Service, Trust & Reputation | Service | ||||
| UNI.614 | Functional Requirement | Security, QoS | A system built using the ARM shall provide Quality of Service | In networks where nodes are constrained devices with limited communication capabilities, QoS might have a new (or extended) meaning compared to the current meaning. For example, real-time, event-triggered data with high time resolution, needs to be delivered with a higher priority than other and might need to ignore the need to sleep of some devices in the network. | Operation, (Deployment), Functional | (none) | IoT Service, Communication, Management | IoT Service Resolution, IoT Service, Hop to Hop Communication, End to End Communication, Network Communication, Performance | Device | ||||
| UNI.615 | Non-functional Requirement | QoS | A system built using the ARM shall provide transport layer fairness | While congestion avoidance is important in any large network, in low bandwidth mesh networks this is essential. | (none) | Perfomance and Scalability | Communication | End to End Communication | Device | ||||
| UNI.616 | Non-functional Requirement | Security, Availability | A system built using the ARM shall ensure network availability | The network functions should be available to network endpoints. Appropriate measures should be taken to avoid network disruption. | (none) | Availability and Resilience | (none specific) | (none specific) | Device | ||||
| UNI.617 | Non-functional Requirement | Security, Integrity | A system built using the ARM shall enforce correct routing | Packet routing over underlying Link Layer should be efficient and should not be subject to disruption by malicious subjects. Disruption could lead to worm/blackhole, exhaustion and DoS attacks. | (none) | Security and Privacy | Communication, Security | Hop to Hop Communication, Trust Authority, Authentication | Device | ||||
| UNI.618 | Non-functional Requirement | Security, Access control | A system built using the ARM shall have a communication control for restricted usage | In some cases hop by hop communication should only be available to authenticated devices. | Functional | Security and Privacy | Communication, Security | Hop to Hop Communication, Authentication | Device | ||||
| UNI.619 | Non-functional Requirement | Security, Non-repudiation | A system built using the ARM shall ensure non repudiation at network level | Mobile devices should be able to join peripheral networks belonging to different provider. Devices entitled to join a given network must be able to do so. | (none) | Security and Privacy | Security | Authorisation, Trust & Reputation, Authentication | Device | ||||
| UNI.620 | Non-functional Requirement | Security, Integrity | A system built using the ARM shall provide Software Integrity | The software execution environment should preserve software integrity. | (none) | Security and Privacy | Security | Certification Authority | Service | ||||
| UNI.622 | Functional Requirement | Security, Integrity | A system built using the ARM shall support device location identification | A node that is considered fixed should not be moved from its position. This could alter the quality of the data provided as it refers to a different position. | Functional | Security and Privacy | Security | Trust & Reputation | Device | ||||
| UNI.623 | Non-functional Requirement | Privacy, Geolocation | A system built using the ARM shall support location privacy | The Location of a Subject should only be available to authorized Subjects. Specific methods for obscuring both network and physical location should be available. | Functional | Security and Privacy | IoT Service, Virtual Entity, Security | IoT Service, Autorisation, VE Resolution, IoT Service Resolution | Service | ||||
| UNI.624 | Non-functional Requirement | Privacy | A system built using the ARM shall provide pseudonymisation mechanisms | While complete anonymity is not feasibe in an IoT scenario, pseudonimity should be supported. | (none) | Security and Privacy | Security | Identity Management | Device, Service, User | ||||
| UNI.625 | Functional Requirement | Security, Privacy, Security management | A system built using the ARM shall provide a device security and privacy measurement | Users should be able to monitor and control the security and privacy settings of all the devices that they own. | Functional | Security and Privacy | Security | (none specific) | Device | ||||
| UNI.626 | Non-functional Requirement | Security, Security management | The IoT should support secure Over-the-Air/Over-the-Network Device Management | The Execution Environment and the Services provided on a given remote device should be securely managed from remote. | (none) | Security and Privacy | Security, Management | Authorisation, Authentication, Device Manager | Device | ||||
| UNI.701 | Non-functional Requirement | Evolvability | A system built using the ARM shall accomodate fast developmental changes in applications and network |
"New applications can change traffic characteristics in a few months. In the past decade several applications dramatically changed the way how the Internet is used. Nobody has actually foreseen the success of P2P networks, and especially Youtube and Facebook. Thus, the question is whether it is possible to design a Future Internet without having any ideas what the “next big things” could be. If thus the traffic changes are unpredictable, then we need to establish a fast and stable infrastructure without any assumptions on the traffic." [G. Drea Rodosek, A. Pras, H. Schulzrinne, and B. Stiller, "Learning from the Past: Implications for the Future Internet and its Management?", Dagstuhl Seminar 11042, 2011] |
(none) | Evolution and Interoperability | (none specific) | (none specific) | (None) | ||||
| UNI.702 | Non-functional Requirement | Evolvability, autonomicity | A system built using the ARM development shall support iterative approaches (e.g. spiral model) |
"The waterfall model does not work in practice in communications, for sure, software is not a “one-time instance”, changes will occur for some time. Thus, versions are needed, and for protocols we may arrive at the same iterative refinement approach." [G. Drea Rodosek, A. Pras, H. Schulzrinne, and B. Stiller, "Learning from the Past: Implications for the Future Internet and its Management?", Dagstuhl Seminar 11042, 2011] |
(none) | (none specific) | (none) | (none specific) | (None) | ||||
| UNI.703 | Design constraint | Architecture | A system built using the ARM shall be based on a cross-layered architecture |
"Full decoupling of planes (management, user, control) is good in an “old-style telco world”, however, it will not work in the Future Internet." [G. Drea Rodosek, A. Pras, H. Schulzrinne, and B. Stiller, "Learning from the Past: Implications for the Future Internet and its Management?", Dagstuhl Seminar 11042, 2011] |
Functional | (none specific) | (none) | (none specific) | (None) | ||||
| UNI.704 | Functional Requirement | Autonomicity | A system built using the ARM shall exhibit self-management behaviour |
There is no future for a centralized management (in most cases). It is necessary to move the research effort towards self-management approaches. [G. Drea Rodosek, A. Pras, H. Schulzrinne, and B. Stiller, "Learning from the Past: Implications for the Future Internet and its Management?", Dagstuhl Seminar 11042, 2011] [S. Kim, M. Choi, H. Ju, M. Ejiri, J. Hong, "Towards management requirements of Future Internet", In: "Challenges for next generation network operations and service management.", Springer, 2008, pp 156–166] |
Functional | (none specific) | Management | Performance, Member, State | (None) | ||||
| UNI.706 | Functional Requirement | Autonomicity | A system built using the ARM shall be capable of self-configuration |
The need for self-configuration in access networks, programmable nodes. [G. Drea Rodosek, A. Pras, H. Schulzrinne, and B. Stiller, "Learning from the Past: Implications for the Future Internet and its Management?", Dagstuhl Seminar 11042, 2011] |
Functional | Performance and Scalability | Management | Configuration, Member | (None) | ||||
| UNI.708 | Functional Requirement | Autonomicity | The system management shall auto-bootstrap |
"The management plane shoud be operationally independent of the data plane and should be able to bootstrap without any pre-configuration." [S. Kim, M. Choi, H. Ju, M. Ejiri, J. Hong, "Towards management requirements of Future Internet", In: "Challenges for next generation network operations and service management.", Springer, 2008, pp 156–166] |
Functional | Performance and Scalability | Management | Configuration, Member | (None) | ||||
| UNI.709 | Functional Requirement | Architecture, Usability | A system built using the ARM shall provide a single, simple management interface for all communication protocols |
"The operational complexity of protocols should be confined to their implementation, and they should express the information required for managing them through a simple management interface. This includes the responsibility on the protocol implementer for a detailed understanding of the protocol operation while reducing the burden on management applications." [S. Kim, M. Choi, H. Ju, M. Ejiri, J. Hong, "Towards management requirements of Future Internet", In: "Challenges for next generation network operations and service management.", Springer, 2008, pp 156–166] |
Functional | (none specific) | Management | (none specific) | (None) | ||||
| UNI.710 | Functional Requirement | Architecture | A system built using the ARM shall include a management repository to store information on the state of the system |
"Management of the Future Internet architecture will require data on the current state of the network, available in real time. The challenge is that the proposed instrumentation systems can potentially gather vast quantities of high-dimensional data. This implies the requirement of a repository unit that will organize the measurement data." [S. Kim, M. Choi, H. Ju, M. Ejiri, J. Hong, "Towards management requirements of Future Internet", In: "Challenges for next generation network operations and service management.", Springer, 2008, pp 156–166] |
Functional | (none specific) | Management | Member, State | (None) | ||||
| UNI.711 | Non-functional Requirement | Scalability | The Internet of Things shall not impact the scalability of the management of the Future Internet. |
"[...] the management systems and operations of Future Internet must be scalable in order to support thousands and millions of different network devices and to provide services." [S. Kim, M. Choi, H. Ju, M. Ejiri, J. Hong, "Towards management requirements of Future Internet", In: "Challenges for next generation network operations and service management.", Springer, 2008, pp 156–166] |
(none) | Performance and Scalability | (none) | (none specific) | (None) | ||||
| UNI.712 | Non-functional Requirement | Interoperability | The Management functionalities of two IoT systems shall be able to interoperate. |
"We assume that there may exist different network management systems that play different roles such as security and performance. Also, interactions occur between network management systems in different domains." [S. Kim, M. Choi, H. Ju, M. Ejiri, J. Hong, "Towards management requirements of Future Internet", In: "Challenges for next generation network operations and service management.", Springer, 2008, pp 156–166] |
(none) | Evolution and Interoperability | Management | (none specific) | (None) | ||||
| UNI.713 | Non-functional Requirement | Performance | Management functionalities shall react to dynamic operation and system changes in real time |
Management system shall react to dynamic operation [and system] changes in real time. |
(none) | Performance and scalability | Management | (none specific) | (None) | ||||
| UNI.714 | Non-functional Requirement | Energy-awareness, Radio-awareness | The system management shall pay attention to device constraints such as energy and memory |
Management system shall meet device constraints such as energy and memory. |
(none) | Performance and scalability | Management | Performance, Member, State | (None) | ||||
| UNI.715 | Functional Requirement | Autonomicity | A system built using the ARM shall perform data collection on its current state |
In order to meet device and system constraints, the collection of system states is important. |
Functional | (none specific) | Management | (none specific) | (None) | ||||
| UNI.716 | Non-functional Requirement | Scalability | Management of the envisioned system shall incur low communication overhead |
"Management should cause as little overhead as possible for the underlying networks considering the resource constraints of the IoT. To fulfill this, unnecessary communication should be avoided. For example, broadcast and multicast messages could be used to replace unicast messages if applicable. History query results could be stored at some proxy points for future queries instead of flooding all query messages into the network. Message headers and data should also be compressed if possible." |
(none) | Performance and scalability | Management | (none specific) | (None) | ||||
| UNI.717 | Functional Requirement | Autonomicity | A system built using the ARM shall be able to perform self-optimisation |
"The system can measure its current performance and it is able to compare it against to the known optimum level of performance. The system will adjust its operation to reach closer the optimal performance. The system is also able to change its operation to cope with new user set policies." |
(none) | Performance and scalability | Management | (none specific) | (None) | ||||
| UNI.718 | Non-functional Requirement | Resilience, Availability, Autonomicity | The system shall be able to perform self-healing |
"The system tries to recover from faults or to avoid them. Self-healing can be implemented in two different styles. They are reactive and proactive modes. In reactive mode the system detects and recovers from faults as they occur. The system also tries to repair the faulted functions if possible. In proactive mode the system monitors its state to detect and adjust its behaviour before reaching an undesired state." |
(none) | Availability and resilience | Management | (none specific) | (None) | ||||
| UNI.719 | Non-functional Requirement | Autonomicity, Resilience, Availability | A system built using the ARM shall be able to perform self-protection |
"The system defends itself against internal and external threats, which can be accidental, such as cascading failures, or malicious attacks against the system. To manage the threats the system must be aware of its environment and have means to react to detected threats." |
(none) | Security and Privacy | Management, Security | Fault, State, Trust and Reputation | (None) | ||||
| UNI.721 | Non-functional Requirement | Architecture | The system management shall be operationally independent of the specifics of the communication functionality. |
"The management plane shoud be operationally independent of the data plane and should be able to bootstrap without any pre-configuration." [S. Kim, M. Choi, H. Ju, M. Ejiri, J. Hong, "Towards management requirements of Future Internet", In: "Challenges for next generation network operations and service management.", Springer, 2008, pp 156–166] |
Functional | (none specific) | Management | (none specific) | (None) |
