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.

[Nielsen, J. (1993). Usability Engineering].

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.

[Nielsen, J. (1993). Usability Engineering].

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.

[IETF Routing over Low Power and Lossy Networks WG charter]

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.

[IETF Routing over Low Power and Lossy Networks WG charter]

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.

[IETF Routing over Low Power and Lossy Networks WG charter]

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.

[IETF Routing over Low Power and Lossy Networks WG charter]

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).

[IETF Routing over Low Power and Lossy Networks WG charter]

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.

[IETF Routing over Low Power and Lossy Networks WG charter]

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"

[ SmartProduct Deliverable: "D6.3.1 & D6.4.1 & D6.5.1 Initial Smart Products Communication Middleware, Initial Sensor and Actuator Integration Framework & Initial Context and Environment Model Framework".]

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"

[ SmartProduct Deliverable: "D6.3.1 & D6.4.1 & D6.5.1 Initial Smart Products Communication Middleware, Initial Sensor and Actuator Integration Framework & Initial Context and Environment Model Framework".]

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."

[ SmartProduct Deliverable: "D6.3.1 & D6.4.1 & D6.5.1 Initial Smart Products Communication Middleware, Initial Sensor and Actuator Integration Framework & Initial Context and Environment Model Framework".]

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"

[ SmartProduct Deliverable: "D6.3.1 & D6.4.1 & D6.5.1 Initial Smart Products Communication Middleware, Initial Sensor and Actuator Integration Framework & Initial Context and Environment Model Framework".]

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

[ SmartProduct Deliverable: "D6.3.1 & D6.4.1 & D6.5.1 Initial Smart Products Communication Middleware, Initial Sensor and Actuator Integration Framework & Initial Context and Environment Model Framework".]

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"

[ SmartProduct Deliverable: "D6.3.1 & D6.4.1 & D6.5.1 Initial Smart Products Communication Middleware, Initial Sensor and Actuator Integration Framework & Initial Context and Environment Model Framework".]

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"

[ BRIDGE Deliverable "D2.1 Requirements document of serial level lookup service for various industries, Section C". ]

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"

[ BRIDGE Deliverable "D2.1 Requirements document of serial level lookup service for various industries, Section C".]

[IOT-A Deliverable "D6.6 Report on Stakeholder Opinions"]

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"

[ BRIDGE Deliverable "D2.1 Requirements document of serial level lookup service for various industries, Section C". ]

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]

[ T. Töyry, "Self-management in Internet of Things"]

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]

[Q. Wang, R. Jäntti, Y. Ali, "On Network Management for the Internet of Things", 8th Swedish National Computer Networking Workshop (SNCNW) , 2012]

(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.

[Q. Wang, R. Jäntti, Y. Ali, "On Network Management for the Internet of Things", 8th Swedish National Computer Networking Workshop (SNCNW), 2012]

(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.

[Q. Wang, R. Jäntti, Y. Ali, "On Network Management for the Internet of Things", 8th Swedish National Computer Networking Workshop (SNCNW), 2012]

(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.

[Q. Wang, R. Jäntti, Y. Ali, "On Network Management for the Internet of Things", 8th Swedish National Computer Networking Workshop (SNCNW) , 2012]

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."

[Q. Wang, R. Jäntti, Y. Ali, "On Network Management for the Internet of Things", 8th Swedish National Computer Networking Workshop (SNCNW) , 2012]

(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."

[ T. Töyry, "Self-management in Internet of Things"]

(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."

[ T. Töyry, "Self-management in Internet of Things"]

(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."

[ T. Töyry, "Self-management in Internet of Things"]

(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)
Document Actions





Internet of Things Architecture © 2009 – 2016