Iot A Uni

This deliverable presents a list of requirements that were gathered in the process of developing the IoT Architectural Reference Model (IoT ARM)
# Uni Id Req Type Category Scratch Description Rationale View Perspective Functionality Group Functional Component Domain Model Remark
1 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 View
2 UNI.066 Functional Requirements Security, Integrity Gateway 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 View
3 UNI.402 Non-Functional Requirement Self-description, Geolocation Gateway 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" "https://web.archive.org/web/20160311232809/http://www.smartproducts-project.eu/media/stories/smartproducts/publications/SmartProducts_D6.345.1_Final.pdf"> 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 View
4 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." "https://web.archive.org/web/20160311232809/http://www.smartproducts-project.eu/media/stories/smartproducts/publications/SmartProducts_D6.345.1_Final.pdf"> 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 View
5 UNI.404 Functional Requirement Self-description, Geolocation Gateway 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" "https://web.archive.org/web/20160311232809/http://www.smartproducts-project.eu/media/stories/smartproducts/publications/SmartProducts_D6.345.1_Final.pdf"> 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 View
6 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 "https://web.archive.org/web/20160311232809/http://www.smartproducts-project.eu/media/stories/smartproducts/publications/SmartProducts_D6.345.1_Final.pdf"> 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 View
7 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" "https://web.archive.org/web/20160311232809/http://www.smartproducts-project.eu/media/stories/smartproducts/publications/SmartProducts_D6.345.1_Final.pdf"> 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 View
8 UNI.409 Functional Requirement Data handling & communication Gateway 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 "https://web.archive.org/web/20160311232809/http://www.bridge-project.eu/data/File/BRIDGE%20WP02%20High%20level%20design%20Discovery%20Services.pdf"> BRIDGE deliverable: "High level design for Discovery Services"." Functional (none) Virtual Entity VE Service Virtual Entity View
9 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" "https://web.archive.org/web/20160311232809/http://www.bridge-project.eu/data/File/BRIDGE%20WP02%20Serial%20level%20lookup%20Requirements.pdf"> 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 View
10 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 View
11 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 View
12 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 View
13 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 View
14 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 View
15 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 View
16 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) View
17 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) View
18 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 View
19 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 View
20 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 View
21 UNI.605 Non-functional Requirement Privacy, Trust Gateway 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 View
22 UNI.606 Non-functional Requirement Privacy, Non-repudiation Policy 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 View
23 UNI.607 Functional Requirement Privacy, Trust Gateway 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 View
24 UNI.608 Functional Requirement Security, Integrity Gateway 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 View
25 UNI.611 Non-functional Requirement Security, Access control Gateway 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 View
26 UNI.612 Non-functional Requirement Security, Privacy, Trust Gateway 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 View
27 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 View
28 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" "https://web.archive.org/web/20160311232809/http://www.bridge-project.eu/data/File/BRIDGE%20WP02%20Serial%20level%20lookup%20Requirements.pdf"> BRIDGE Deliverable "D2.1 Requirements document of serial level lookup service for various industries, Section C"." "/web/20160311232809/http://www.iot-a.eu/public/public-documents/documents-1/1/1/d6.6/at_download/file">IOT-A Deliverable "D6.6 Report on Stakeholder Opinions"" Deployment Security and Privacy Virtual Entity VE Resolution Services View
29 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) ? View
30 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) View
31 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) View
32 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 View
33 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 View
34 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 View
35 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 View
36 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 View
37 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 View
38 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 View
39 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 View
40 UNI.031 Functional Requirements Service composition & programmability Gateway 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 View
41 UNI.032 Functional Requirements Service composition & programmability, Usage Gateway 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 View
42 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 View
43 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 View
44 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 View
45 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 View
46 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 View
47 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 View
48 UNI.087 Functional Requirements Service composition & programmability Gateway 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 View
49 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 View
50 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 View
51 UNI.236 Functional Requirement QoS, Data Handling and communication, Usage Gateway 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 View
52 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 View
53 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 View
54 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 View
55 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 View
56 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 View
57 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 View
58 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. "https://web.archive.org/web/20160311232809/http://dl.acm.org/citation.cfm?id=529793">Nielsen, J. (1993). Usability Engineering". Functional (none) Service Organization Service Composition, Service Orchestration Service View
59 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. "https://web.archive.org/web/20160311232809/http://dl.acm.org/citation.cfm?id=529793">Nielsen, J. (1993). Usability Engineering". Operation (none) Service Organization Service Composition, Service Orchestration Service View
60 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 View
61 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 View
62 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 View
63 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 View
64 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 View
65 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 View
66 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 View
67 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) View
68 UNI.023 Non-functional Requirements Interoperability, Enterprise Integration Gateway 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 View
69 UNI.507 Non-functional Requirement Security, Privacy, Data handling & communication Gateway 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 View
70 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 View
71 UNI.237 Functional Requirement QoS, Data Handling and communication Gateway 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 View
72 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 View
73 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 View
74 UNI.041 Functional Requirements Data handling & communication Gateway 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 View
75 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 View
76 UNI.301 Functional Requirement Data handling & communication Gateway 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) View
77 UNI.302 Functional Requirement Data handling & communication Gateway 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) View
78 UNI.303 Functional Requirement Data handling & communication Gateway 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) View
79 UNI.304 Functional Requirement Data handling & communication Gateway 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) View
80 UNI.305 Functional Requirement Data handling & communication Gateway 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) View
81 UNI.306 Functional Requirement Data handling & communication Gateway 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. "https://web.archive.org/web/20160311232809/http://datatracker.ietf.org/doc/charter-ietf-roll/">IETF Routing over Low Power and Lossy Networks WG charter" Functional (none) Communication (none specific) Devices (Sensors, Tags, Actuators) View
82 UNI.307 Functional Requirement Data handling & communication Gateway 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. "https://web.archive.org/web/20160311232809/http://datatracker.ietf.org/doc/charter-ietf-roll/">IETF Routing over Low Power and Lossy Networks WG charter" Functional (none) Communication (none specific) Devices (Sensors, Tags, Actuators) View
83 UNI.308 Functional Requirement Data handling & communication, Resilience Gateway 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. "https://web.archive.org/web/20160311232809/http://datatracker.ietf.org/doc/charter-ietf-roll/">IETF Routing over Low Power and Lossy Networks WG charter" Functional (none) Communication Hop to Hop Communication, Network Communication Devices (Sensors, Tags, Actuators) View
84 UNI.309 Functional Requirement Data handling & communication, Energy-awareness Gateway 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) View
85 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. "https://web.archive.org/web/20160311232809/http://datatracker.ietf.org/doc/charter-ietf-roll/">IETF Routing over Low Power and Lossy Networks WG charter" Functional (none) Communication Hop to Hop Communication, Network Communication Devices (Sensors, Tags, Actuators) View
86 UNI.311 Functional Requirement Data handling & communication Gateway 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) View
87 UNI.312 Functional Requirement Data handling & communication, Interoperability Gateway 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) View
88 UNI.313 Functional Requirement Data handling & communication, Interoperability Gateway 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) View
89 UNI.314 Functional Requirement Data handling & communication Gateway 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). "https://web.archive.org/web/20160311232809/http://www6.ietf.org/proceedings/79/slides/nbs-0.pdf">IETF 79 proceedings" Functional Evolution and Interoperability Communication Network Communication Devices (Sensors, Tags, Actuators) View
90 UNI.315 Functional Requirement Data handling & communication Gateway 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). "https://web.archive.org/web/20160311232809/http://datatracker.ietf.org/doc/charter-ietf-roll/">IETF Routing over Low Power and Lossy Networks WG charter" Functional (none) Communication Network Communication Devices (Sensors, Tags, Actuators) View
91 UNI.318 Functional Requirement Data handling & communication Gateway 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. "https://web.archive.org/web/20160311232809/http://datatracker.ietf.org/doc/charter-ietf-roll/">IETF Routing over Low Power and Lossy Networks WG charter" Functional (none) Communication Hop to Hop Communication, Network Communication Devices (Sensors, Tags, Actuators) View
92 UNI.319 Functional Requirement Data handling & communication, Access control Gateway 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) View
93 UNI.320 Functional Requirement Data handling & communication Gateway 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) View
94 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) View
95 UNI.322 Functional Requirement Data handling & communication, Privacy Gateway 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) View
96 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) View
97 UNI.326 Functional Requirement Data handling & communication, Interoperability Gateway 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) View
98 UNI.327 Functional Requirement Data handling & communication, Interoperability Gateway 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) View
99 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) View
100 UNI.624 Non-functional Requirement Privacy Gateway 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 View
101 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 View
102 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 View
103 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 View
104 UNI.096 Functional Requirements Autonomicity, Self-Configuration Gateway 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 View
105 UNI.609 Non-functional Requirement Security, Integrity Gateway 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 View
106 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 View
107 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 View
108 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 View
109 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 View
110 UNI.501 Non-functional Requirement Security Gateway 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 View
111 UNI.503 Functional Requirement Usage, Security, Integrity, Non-Repudiation, Privacy Gateway 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 View
112 UNI.020 Functional Requirements Radio-awareness Gateway 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 View
113 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 View
114 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 View
115 UNI.506 Design Constraint Interoperability, Data handling & communication Gateway 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 View
116 UNI.510 Functional Requirement Security Gateway 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 View
117 UNI.614 Functional Requirement Security, QoS Gateway 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 View
118 UNI.615 Non-functional Requirement QoS Gateway 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 View
119 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 View
120 UNI.617 Non-functional Requirement Security, Integrity Gateway 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 View
121 UNI.618 Non-functional Requirement Security, Access control Gateway 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 View
122 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 View
123 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 View
124 UNI.625 Functional Requirement Security, Privacy, Security management Gateway 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 View
125 UNI.626 Non-functional Requirement Security, Security management Gateway 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 View
126 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 View
127 UNI.401 Functional Requirement Discovery & lookup, Geolocation Gateway 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" "https://web.archive.org/web/20160311232809/http://www.smartproducts-project.eu/media/stories/smartproducts/publications/SmartProducts_D6.345.1_Final.pdf"> 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) View
128 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 View
129 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" "https://web.archive.org/web/20160311232809/http://www.bridge-project.eu/data/File/BRIDGE%20WP02%20Serial%20level%20lookup%20Requirements.pdf"> 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) View
130 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) View
131 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) View
132 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) View
133 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) View
134 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) View
135 UNI.233 Design Constraint Data Handling & communication Gateway 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 View
136 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) View
137 UNI.005 Functional Requirements Autonomicity, Data handling & Communication Gateway 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) View
138 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) View
139 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) View
140 UNI.026 Functional Requirements QoS, Data handling and communication Gateway 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) View
141 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) View
142 UNI.062 Design constraints Security, Trust, Data handling & communication Availability, Integrity Gateway 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) View
143 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) View
144 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) View
145 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) View
146 UNI.097 Functional Requirements Data handling & communication Gateway 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) View
147 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) View
148 UNI.100 Functional Requirements Resource control Gateway 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) View
149 UNI.101 Functional Requirements Energy-awareness, Resource Control Gateway 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) View
150 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) View
151 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) View
152 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) View
153 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) View
154 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) View
155 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) View
156 UNI.232 Functional Requirement Interoperability Gateway 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) View
157 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) View
158 UNI.235 Functional Requirement QoS, Data Handling and communication Gateway 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) View
159 UNI.508 Non-functional Requirement Data handling & communication Gateway 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) View
160 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) View
161 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) View
162 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) View
163 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) View
164 UNI.703 Design constraint Architecture Gateway 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) View
165 UNI.704 Functional Requirement Autonomicity Gateway 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) View
166 UNI.706 Functional Requirement Autonomicity Gateway 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" "https://web.archive.org/web/20160311232809/https://wiki.aalto.fi/download/attachments/59704179/toyry-self-management.pdf?version=1&modificationDate=1324369262000"> T. Töyry, "Self-management in Internet of Things"" Functional Performance and Scalability Management Configuration, Member (None) View
167 UNI.708 Functional Requirement Autonomicity Gateway The system management shall auto-bootstrap "The management plane should 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) View
168 UNI.709 Functional Requirement Architecture, Usability Gateway 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) View
169 UNI.710 Functional Requirement Architecture Gateway 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) View
170 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" "https://web.archive.org/web/20160311232809/http://users.tkk.fi/wangq1/SNCNW_OnNetworkManagement.pdf">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) View
171 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) View
172 UNI.713 Non-functional Requirement Performance Gateway 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. "https://web.archive.org/web/20160311232809/http://users.tkk.fi/wangq1/SNCNW_OnNetworkManagement.pdf">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) View
173 UNI.714 Non-functional Requirement Energy-awareness, Radio-awareness Gateway 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. "https://web.archive.org/web/20160311232809/http://users.tkk.fi/wangq1/SNCNW_OnNetworkManagement.pdf">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) View
174 UNI.715 Functional Requirement Autonomicity Gateway A system built using the ARM shall perform data collection on its current state Functional (none specific) Management (none specific) (None) View
175 UNI.716 Non-functional Requirement Scalability Gateway 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." "https://web.archive.org/web/20160311232809/http://users.tkk.fi/wangq1/SNCNW_OnNetworkManagement.pdf">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) View
176 UNI.717 Functional Requirement Autonomicity Gateway 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." "https://web.archive.org/web/20160311232809/https://wiki.aalto.fi/download/attachments/59704179/toyry-self-management.pdf?version=1&modificationDate=1324369262000"> T. Töyry, "Self-management in Internet of Things"" (none) Performance and scalability Management (none specific) (None) View
177 UNI.718 Non-functional Requirement Resilience, Availability, Autonomicity Gateway 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." "https://web.archive.org/web/20160311232809/https://wiki.aalto.fi/download/attachments/59704179/toyry-self-management.pdf?version=1&modificationDate=1324369262000"> T. Töyry, "Self-management in Internet of Things"" (none) Availability and resilience Management (none specific) (None) View
178 UNI.719 Non-functional Requirement Autonomicity, Resilience, Availability Gateway 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." "https://web.archive.org/web/20160311232809/https://wiki.aalto.fi/download/attachments/59704179/toyry-self-management.pdf?version=1&modificationDate=1324369262000"> T. Töyry, "Self-management in Internet of Things"" (none) Security and Privacy Management, Security Fault, State, Trust and Reputation (None) View
179 UNI.721 Non-functional Requirement Architecture Gateway 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 to 166" Functional (none specific) Management (none specific) (None) View
180 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) View
181 UNI.028 Functional Requirements QoS, Data handling and communication Gateway 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) View
182 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) View
183 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) View
184 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) View
Records : 184 of 184 | Page : of 1 | Limit