7.1 Introduction
7.2 Interaction of All Sub-Models
7.3 Domain Model
7.3.1 Definition and Purpose
7.3.2 Main Abstractions and Relationships
7.3.2.1 Interpreting the Model Diagram
7.3.2.2 The Concepts of the IoT Domain Model
-
They are Digital Artefacts. Virtual Entities are associated to a single Physical Entity and the Virtual Entity represents this very Physical Entity. While there is generally only one Physical Entity for each Virtual Entity, it is possible that the same Physical Entity can be associated to several Virtual Entities, e.g., a different representation per application domain. Each Virtual Entity must have one and only one ID that identifies it univocally. Virtual Entities are Digital Artefacts that can be classified as either active or passive. Active Digital Artefacts (ADA) are running software applications, agents or Services that may access other Services or Resources. Passive Digital Artefacts (PDA) are passive software elements such as database entries that can be digital representations of the Physical Entity. Please note that all Digital Artefacts can be classified as either Active or Passive Digital Artefacts;
-
Ideally, Virtual Entities are synchronised representations of a given set of aspects (or properties) of the Physical Entity. This means that relevant digital parameters representing the characteristics of the Physical Entity are updated upon any change of the former. In the same way, changes that affect the Virtual Entity could manifest themselves in the Physical Entity. For instance, manually locking a door might result in changing the state of the door in home automation software, and correspondingly, setting the door to “locked” in the software might result in triggering an electric lock in the physical world.
-
Sensors provide information, knowledge, or data about the Physical Entity they monitor. In this context, this ranges from the identity of the Physical Entity to measures of the physical state of the Physical Entity. Like other Devices, they can be attached or otherwise embedded in the physical structure of the Physical Entity, or be placed in the environment and indirectly monitor Physical Entities. An example for the latter is a face-recognition enabled camera. Information from sensors can be recorded for later retrieval (e.g., in a storage of Resource);
-
Tags are used to identify Physical Entities, to which the Tags are usually physically attached. The identification process is called “reading”, and it is carried out by specific Sensor Devices, which are usually called readers. The primary purpose of Tags is to facilitate and increase the accuracy of the identification process. This process can be optical, as in the case of barcodes and QR codes, or it can be RF-based, as in the case of microwave car-plate recognition systems and RFID. The actual physics of the process, as well as the many types of tags, are however irrelevant for the IoT Domain Model as these technologies vary and change over time. These are important however when selecting the right technology for the implementation of a concrete system;
-
Actuators can modify the physical state of a Physical Entity, like changing the state (translate, rotate, stir, inflate, switch on/off,…) of simple Physical Entities or activating/deactivating functionalities of more complex ones.
7.3.3 Detailed Explanations and Related Concepts
7.3.3.1 Devices and Device Capabilities
7.3.3.2 Resources
7.3.3.3 Services
-
Resource-level Services expose the functionality, usually of a Device, by accessing its hosted Resources. These kinds of Services refer to a single Resource. In addition to exposing the Resource’s functionality, they deal with quality aspects, such as dependability, security (e.g., access control), resilience (e.g., availability) and performance (e.g., scalability, timeliness). Resources can also be Network Resources, i.e. the Resources do not necessarily reside on a Device in the sense of the IoT Domain Model (normal computers are not regarded as IoT Devices by the IoT Domain Model), but can also be hosted somewhere else. The concrete location of where the Network Resource is situated is commonly abstracted away by the Service;
-
Virtual Entity-level Services provide access to information at a Virtual Entity-level. They can be Services associated to a single Virtual Entity that give access to attributes for reading attribute information or for updating attributes in order to trigger associations. An alternative is to provide a common Virtual Entity-level Service with an interface for accessing attributes of different Virtual Entities, as, for instance, the NGSI Context Interface (NGSI 2010) provides for getting attribute information of the Virtual Entities;
-
Integrated Services are the result of a Service composition of Resource-level or Virtual Entity-level Services as well as any combinations of both Service abstractions.
7.3.3.4 Identification of Physical Entities
7.3.3.5 Context and Location
7.4 Information Model
7.4.1 Definition of the IoT Information Model
7.4.2 Modelling of Example Scenario
7.4.3 Relation of Information Model to Domain Model
7.4.4 Other Information-Related Models in IoT-A
-
Entity model: The Entity Model specifies which attributes and features of real word objects are represented by the virtual counterpart, i.e. the Virtual Entity of the respective Physical Entity. For every attribute specified in the entity model, services can be found that are able to either provide information about the attribute (sensing) or manipulate it, leading to an effect in the real world (actuating). More information about the entity model can be found in Sect. 7.1.3.2.2.
-
Resource model: The Resource Model contains the information that is essential to identify Resources by a unique identifier and to classify Resources by their type, like sensor, actuator, processor or tag. Furthermore the model specifies the geographic location of the Resource, the Device the Resource is hosted on (if so) as well as the IoT Services the Resource is exposed through. More information can be found in (Martin 2012) Sect. 3.3.
-
Service description model: Services provide access to Resources and are used to access information or to control Physical Entities. An IoT Service accesses IoT Resources in order to provide information about attributes of entities or manipulates them leading to an effect in the real world. A Service Description describes a Service, using for instance a service description language such as USDL.1 For more information see (Martin 2012) Sect. 4.6.3.
-
Event Model: Event models are quite essential in today’s IoT architectures, e.g. in the EPCglobal Information Services. Normally events are used to track dynamic changes in a (software) system, showing who or what has triggered it and when, where and why the change occurred. Event representation and processing is specified in Sect. 4.2 of (Voelksen 2013).
7.5 Functional Model
7.5.1 Functional Decomposition
-
The Functional Model (purpose of this section);
-
The Functional View (presented in Sect. 8.2.2).
-
Abstract: The Functional Model is not directly tied to a certain technology, application domain, or implementation. It does not explain what the different Functional Components are that make up a certain Functionality Group;
-
Functionality Groups and their interactions: The Functional Model contains both the Functionality Groups and the interaction between those parts. A list of the Functionality Groups alone would not be enough to make up the Functional Model. Both the Functionality Groups and their interaction are mandatory;
-
Functional View: The Functional View describes the system’s runtime Functional Components, including the components’ responsibilities, their default functions, their interfaces, and their primary interactions. The Functional View is derived from the Functional Model on the one hand and from the Unified Requirements on the other hand. Note that various Functional Views could be derived from the Functional Model. See also Sect. 8.2.2 for more detailed information on the functional view.
7.5.2 Functional Model Diagram
-
From the main abstractions identified in the Domain Model (Virtual Entities, Devices, Resources and Users) the “Application”, “Virtual Entity”, “IoT Service” and “Device” FGs are derived;
-
With regards to the plethora of communication technologies that the IoT ARM needs to support, the need for a “Communication” FG is identified;
-
Requirements expressed by stakeholders regarding the possibility to build services and applications on top of the IoT are covered by the “IoT Process Management” and “Service Organisation” FGs;
-
To address consistently the concern expressed about IoT Trust, Security and Privacy, the need for a “Security” transversal FG is identified;
-
Finally, the “Management” transversal FG is required for the management of and/or interaction between the functionality groups.
7.5.2.1 IoT Process Management
-
Permission: what can be done? For instance a self-regulating ventilation system can be started by a central control system;
-
Prohibition: what must not be done? For instance the ventilation system may not be shut down in its entirety if the outside temperature is above a pre-defined value and if humans are present in the building;
-
Obligations: the central control system needs to save recorded environmental parameters for each room in the entire building (temperature, humidity, ventilation settings). Such records can, for instance, be required by national occupational-health laws.
7.5.2.2 Service Organisation
7.5.2.3 Virtual Entity and IoT Service
7.5.2.3.1 Virtual Entity
7.5.2.3.2 IoT Service
7.5.2.4 Communication
7.5.2.5 Management
-
Cost reduction;
-
Attending unexpected usage issues;
-
Fault handling; and
-
Flexibility.
-
Prediction of potential failures;
-
Detection of existing failures;
-
Reduction of the effects of failures;
-
Repair.
-
Management of the membership and accompanying information of a given entity to the IoT system. Such entity may be a Functional Component (FC), a Virtual Entity, an IoT Service, an application, a Device. The information considered may cover ownership, administrative domain, capabilities, rules, and rights;
-
Retrieval of the list of members pertaining to a given property such as the ownership/administrative domain;Finally, some more examples for the above goals are provided:
-
Enforcing rules attached to the usage of a certain entity e.g.
-
Attending unexpected events: A service needs temperature measurements every microsecond, but the rule file for the associated device says: maximum measurement frequency of this device is 100 Hz. The rule file also might say: no continuous operation of said device for more than 1 h (due to energy constraints);
-
Fault handling: A service wants to run a business process that would consume all IoT services and the VE lookup for more than a day. An example for this is a query for the geo-location of all temperature Sensors on planet Earth. The rule file may contain instructions about how many resources can be consumed by an application;
-
Cost reduction: Logging entity usage by a user for further processing (e.g. billing).
-
-
Bringing the entire system to an emergency stop, for instance a train;
-
Turning the entire system into a sleep/energy-saving mode in order to relax to load on a failing Smart Grid.
7.5.2.6 Security
7.6 Communication Model
7.6.1 IoT Domain Model Element Communications
7.6.1.1 User-Service / Service-Service Interactions
7.6.1.2 Service / Resource / Device Interactions
7.6.2 Communication Interoperability Aspects
-
Physical aspect: This interoperability aspect concerns the physical characteristics of the communication technologies used in the system. It is similar to the OSI Physical Layer. This is necessary in order to neither exclude any available technology, and to prevent emerging solutions from being integrated into the Reference Model. This aspect does not force the adoption of any specific technology, but it uses the adopted technologies as a base to model the remaining of the system. In fact, as per the recurring example the Mote Runner Node can communicate using some low-power radio transceiver such as ZigBee, while the AndroidApp can be hosted in an IoT-Phone connected to the Internet either via WiFi or 3G cellular networks;
-
Link aspect: In order to address the heterogeneousness of networking technologies represented in the IoT field, the Link aspect requires special attention. In fact, most networks implement similar, but customised communication schemes and security solutions. In order for IoT systems to achieve full interoperability, as well as the support of heterogeneous technologies and a comprehensive security framework, this layer must support solution diversity. At the same time, it needs to provide upper layers with standardised capabilities and interfaces. Therefore, this layer needs to abstract a large variety of functionalities, enabling direct communication. IoT systems do not have to restrict the selection among data link layers, but must enable their coexistence;
-
Network and ID aspect: This interoperability aspect combines two communication aspects: networking, which provides the same functionalities as the correspondent OSI layer; and identifiers, which are provided using resolution functionalities between locators and IDs. In order to support global manageability, interoperability, and scalability, this aspect needs to provide a common communication paradigm for every possible networking solution. This is the narrow waist for the Internet of Things. The difference between identifiers (unique descriptors of the Digital Artefact; either active or passive), and locators (descriptors of the position of a given IoT element in the network), is the first convergence point in the IoT Communication Model. Thus, this interoperability aspect is in charge of making any two systems addressable from one another notwithstanding the particular technologies they are adopting. In the case of our recurring example the AndroidApp must be able to receive alarms generated by the alarm Service, which in turns, must receive information from the Mote Runner Device: in order for this to be possible the system must ensure that the correct identifiers are supported by all the communicating technologies or can be resolved via appropriate methods;
-
End-to-end aspect: this aspect takes care of reliability, transport issues, translation functionalities, proxies/gateways support and parameter configuration when the communication crosses different networking environments. By providing additional interoperability aspects on top of those of the Network and ID aspect, this aspect provides the final component for achieving a global M2M communication model. Connections are also part of the end-to-end scope. Also, Application Layer aspects are taken care of here. Moreover Application Protocols in the IoT tend to embed confirmation messages, and congestion control techniques require being more complex than what is achievable in the Transport Layer in the legacy models. With reference to the recurring example, this aspect will take care of modelling the overall communication between the Alarm Service and the Mote Runner Node and between the AndroidApp and the Alarm Service;
-
Data aspect: the topmost aspect of the IoT Communication Model is related to data definitions and transfers. While the Information Model provides a high-level description for data of IoT systems, the purpose of this aspect is to model data exchange between any two actors in the IoT. As described in the IoT Information Model (see Sect. 7.4), data exchanged in IoT can adopt many different representations, ranging from raw data to complex structures where meta-information is added to provide context specific links. Finally, to make this possible, the data aspect needs to model the following characteristics (Rossi 2013): (1) capability of providing structured attributes for data description; (2) capability of being translated (possibly by compression/decompression) the one to each other, e.g. CoAP is translatable to HTTP by decompression or XML is translatable to EXI by compression, IPv4 is translatable to IPv6 by mapping; (3) constrained device support. For instance, in the recurring example, the raw data produced by the Mote Runner Sensors shall be converted into machine-readable formats in order for the Alarm Service to be able to interpret and use them.
7.6.3 Composed Modelling Options
7.6.3.1 Gateway Configuration
7.6.3.2 Virtual Configuration
7.6.4 Channel Model for IoT Communication
-
Unconstrained networks are characterised by high-speed communication links (e.g., offering transfer rates in the Mbit/s range or higher) like, for instance, the wired Internet of today. Link-level transfer latencies are also small and mainly impacted by congestion events in the network rather than by the physical transmission technology;
-
Constrained networks are characterised by relatively low transfer rates, typically smaller than 1 Mbit/s, as offered by, e.g., IEEE 802.15.4. These networks are also characterised by large latencies. These are due to several factors including: (1) the involved low-bitrate physical layer technology and (2) the power-saving policy of the terminals populating these networks, which may imply the periodic power off of their radios for energy-efficiency reasons.
7.7 Trust, Security, Privacy
7.7.1 Trust
-
The Trust-Model domains: In complex systems that include multi-faceted entities, like, e.g., the IoT, a model that equally shapes the Trust of all components is difficult, if not impossible, to define. For this reason, various domains within the system should be determined, with every domain defining a specific set of subjects to which certain aspects of the trust model apply;
-
Trust-evaluation mechanisms: They define a coherent and safe methodology for computing the trustworthiness degree of a subject within the system. Evaluation mechanisms are based on information previously collected on the given subject. Depending on the application scenario, this information can be obtained by direct experiences with the subject, witness information on the subject coming from other members of a community, social-network analysis providing sociological information on the subject and so on. A trust-evaluation mechanism must take into account the source of the information on which the trust value is being computed, i.e. the trustworthiness of the source itself, and carefully weight its information accordingly in computing the final trust value;
-
Behaviour policies: They regulate the ways two subjects within the same Trust Model domain interact according to their trustworthiness value. They define how subjects that use the system may interact with other subject. E.g., if a wireless sensor A is asked to handle a multi-hop message coming from a sensor B with a very low trust value, Sensor A might decide, according to the behaviour policies defined by the Trust Model, to not accept the message from Sensor B. Though it is not recommended, a Trust Model can define specific behaviours for interacting with subjects whose trust-value cannot be computed within that model;
-
Trust anchor: It is a subject trusted by default (possibly after authentication) by all subjects using a given Trust Model, and exploited in the evaluation of third parties’ trustworthiness. In the IoT environment the trust anchor can either be local to a given subnetwork – running on a node in the same peripheral network, e.g. a gateway – or a global and centralised device that is deployed on the Internet;
-
Federation of trust: It delineates the rules under which trust relationships among systems with different Trust Models can be defined. The federation of trust is essential in order to provide interoperability between subjects that use different Trust Models. The federation of trust becomes particularly important within an IoT system deployed on a large scale, where the coexistence of many different Trust Models it is very likely;
-
M2M support: The interaction among autonomous machines is deemed very common in IoT systems. Prior dynamically identifying and accessing resources of one-another, these machines should be able to autonomously, according to the specifics in the Trust Model, evaluate the trustworthiness of each-other.
7.7.2 Security
7.7.2.1 Communication Security
-
Protocol adaptation between different networks (by definition);
-
Tunnelling between themselves and other nodes of the NTU domain. (Optional; impacts on trust assessment);
-
Management of security features belonging to the peripheral network (Optional);
-
Description of security options related to traffic originated from a node attached to the gateway. (Authentication of source node, cryptographic strength, …);
-
Filtering of incoming traffic (i.e. traffic sent to one of the nodes attached to the gateway or vice-versa) according to network policies, user-defined policies, and destination-node preferences (Optional).
7.7.2.2 Application Security: System Safety and Reliability
7.7.3 Privacy
-
The subject must be able to choose sharing or not sharing information with someone else;
-
The subject must be able to fully control the mechanism used to ensure their privacy;
-
The subject shall be able to decide for which purpose the information will be used;
-
The subject shall be informed whenever information is used and by whom;
-
During interactions between a subject and an IoT system, only strictly needed information shall be disclosed about the subject, and pseudonyms, secondary identity, or assertions (certified properties of the end-user) shall be used whenever possible;
-
It shall not be possible to infer the subject’s identity by aggregating/reasoning over information available at various sources;
-
Information gained for a specific purpose shall not be used for another purpose. E.g., the bank issuing a credit card should not use a given client’s purchase information (logged so to keep track of that client’s account) to send him advertising on goods similar to his purchases.
Threat | Result | Mitigation |
---|---|---|
Identity spoofing | User’s identity is spoofed | Robust user authentication procedure preventing man-in-the-middle attacks, with proper credentials-management policy provided by an Authentication FC
|
User is involved in transactions with a malicious peer | Trustworthy discovery / resolution / lookup system. Trustworthiness of the entire system is guaranteed through its security components (especially Authentication FC and Trust and Reputation FC) as well as its global robustness (security by design) | |
Information disclosure | Attacker gains knowledge of user’s private parameters | The Identity Management FC enforces a robust pseudonymity scheme that ensures anonymity and unlinkability |
Attacker gains knowledge of user’s location | User’s location can be hidden through reliance on pseudonyms provided by Identity Management FC
|
-
Has age over 18 years old;
-
Has valid driving license;
-
Has certification level x.
-
Management;
-
Operational;
-
Maintenance,…
-
assertion: Authenticate (UserCredential)
-
where UserCredential is any kind of information used by the Authenticate functionality to check the identity of the party to be authenticated (e.g. username – password pair, PIN code, retinal identification and so on).
-
assertion (following definition of (Gruschka and Gessner 2012)) is the information that guaranties the occurrence of an authentication of a user client at a particular time using a particular method of authentication. The assertion is further used by the Authorisation (AuthS) component in order to decide upon granting or denying access to a resource.
-
Boolean: Authorise (Assertion, Resource, ActionType),
-
where Assertion is the result of Authentication, Resource represents the resource to be accessed, and ActionType represents the action to be performed upon the resource.