Abstract
The success of IoT technologies is undeniable. They are entering more and more in our lives, carrying out increasingly complex tasks. However, there are still a few problems we need to face and solve. For instance, it is not given that the users will be prepared to afford all the automation that IoT devices will offer or that it will be compatible with the users’ cognitive attitudes and its actual and real goals. Within this work, we start analyzing which reasons undermine the acceptance of IoT systems and then we propose a possible solution, tanking into account not just the user-device interaction, but also how this affects the device-device interaction. Since the complexity of the tasks the user asks may require the cooperation of some devices to be realized, the regulation of this relationship represents a necessary step for this technology. The first contribution of this work is the level characterization of the autonomy a user can grant to an IoT device. The second contribution is a theoretical model to deal with users and to stimulate users’ acceptance, taking also into account a possible, collaborative organizational structure, to manage the creation of groups and the partners’ selection process.
Keywords
Introduction
The incredibly fast improvement of technologies in the age of computer has led to an astonishing revolution in our lives: they way we communicate, think and act have completely changed. In this respect, the Internet of Things (IoT) seems to be a promising sector, which is based on the idea that every object can be connected through Internet. The novelty in all this concerns the fact that the IoT technology is not just limited to the evolution of the classic devices, but it makes smart objects that are not, those we use in our daily life. Just to have an idea of the numbers, it is expected that in 2020 there will be as much as 26 billion units connected to the Internet [15]. These objects will be able communicate with each other in any moment and location[1], providing and receiving services anywhere and anytime.
Being made of smart objects, even the environments will become smart: houses, streets, transportation, hospitals, schools and whole cities. Starting from simple services, smart devices will offer more and more complex and useful services, in order to satisfy the users’ needs. Furthermore, it seems that [20] realizing complex services, together with the compatibility with other device, will affect positively the user perception of IoT’s usefulness.
These systems are not immediately applicable in practice, at least not effectively. While it is true that we have a multitude of extremely useful scenarios, there are also considerable security and privacy issues [23]. Certainly, we are not talking about an apocalyptic prospective, but if in everyday life a hacker is able to block our computer, just think about the damage he could make if he decided to block our home doors. This problem is further enhanced by the heterogeneity of the devices, making it more difficult to control and detect security flaws. If it is already difficult to accept that an object possesses intelligence and can interface with us, the thought that it can revolt against us, causing substantial damage, could make it even more difficult to spread IoT systems. Moreover, in a dynamic world, full of users and devices moving continuously, in which the firsts have different necessities and the latters offer heterogeneous resources and are able to carry out a lot of various tasks, it is also necessary to provide a methodology for collaboration, in the most efficient and flexible way. We need a practical way to regulate the interaction between the user and IoT systems, i.e. the relationships user-device and device-device.
We then argue that a good way to address this problem is through the concept of trust. The key point is in fact that users do not trust these systems; they do not know them or what they can do. The concept of trust [6] comes spontaneously into play. Moreover, when we talk about cooperation, regardless of whether it concerns humans or artificial machines, trust becomes essential: it is in fact possible to cooperate only in presence of trust. We need to be able to evaluate the other, to understand how good it is, in order to identify the best partner for the task we require. Borrowing the concept of trust from the cognitive sciences and introducing it on IoT, we are interested in how trustworthy a device is on providing a specific service. Trust can be seen as an alternative metrics to evaluate the devices. We will see later that introducing trust on the individual features, not just at service level, allows us a better perspective on the devices’ performance. Thus, we propose a general IoT system able to adapt to the specific user and its disposition towards this technology, with the aim of (1) identifying the acceptance limit the user has and (2) pushing the user to accept more this technology. The final purpose of our work is not just achieving a better understanding of how humans relate to IoT systems, but also introducing a novel approach to the design of IoT systems taking into account the central role of the user. After describing the model at a theoretical level, we will inquire its soundness by proposing a possible implementation within a simulated environment. Simulation modeling represents a valuable approach for testing and validate possible solutions, allowing us getting clear insights about complex systems.
When it comes to model a complex system starting from its basic autonomous entities, agent-based modeling (ABM) automatically springs to mind, allowing for a natural decomposition of the system into multiple sub-components - agents - that flexibly interact with each other to achieve a desired global goal. Moreover, ABM offers us also the possibility to model the system with the desired level of abstraction, as evidenced in several field [7, 21] and also specifically for IoT systems [18]. In our specific case, the agents will not pursue utilitarian goals, but they will just try to satisfy the user. Nevertheless, they will think and act as autonomous entities, not as components of a global system: they may have different optimization criteria or they may pursue conflicting goals.
User attitude toward IoT
IoT systems include a wide variety of technologies, so it is not easy to identify in detail the common characteristics and the feature they should possess. However, in a high-level vision, some key aspects often and recurrently come into play.
For sure, a salient topic is that of security [16, 29], in the way that computer science means it. A device must be secure, and the reason is clear: if we give the green light to such a pervasive technology, able to enter deeply into every aspect of our life, it is fundamental that there are no security breaches. For instance, even our toaster could be able to steal money from our bank account; we need to be sure that similar scenarios will not happen. Security mainly relies on encryption to solve its problems.
Then privacy comes into play. As the device will exchange impressive amounts of information, more than can concretely be processed [28], it is not clear which information will be shared and with whom [25]. We need a new way to deal with privacy, since the classical approach of authentication [22] and policies cannot work properly in such a huge and heterogeneous environment. Facing privacy is necessary, but still not enough.
A third element is trust. Usually it is applied to identify trustworthy devices in a network, separating them from the malicious ones [3]. By the way, the authors of [32] provide a review of the use of trust in IoT systems. The same authors identify that trust “helps people overcome perceptions of uncertainty and risk and engages in user acceptance”. In fact, when we have autonomous tools able to take various different decisions and these decisions involve our own goals and results, we have to be worried not just about their correct functioning (for each of these decisions) but also about their autonomous behavior and the role it plays for our purposes.
All these components are valid and fundamental to an IoT system. However, a further point should be emphasized. Although an IoT device requires only the connection and interfacing with the outside world to be defined as such, and then the possibility of being addressed and of exchanging information with the outside world, they are not independent systems, but on the contrary these systems continually interact with users, they relate to them in a very strong way: the user is at the center of everything. In fact, reasoning in view of the goals that these objects possess, the common purpose is to make life better for users, be they the inhabitants of a house, a city, patients/doctors in a hospital, or the workers of a facility.
The user becomes the fundamental point in all of this. A technology can be potentially perfect and very useful but, if people do not accept it, each effort is useless and it goes out of use. It is necessary to keep in mind how much the user is willing to accept an IoT system and to what extent he wants to interface with it. We would like to focus on this last point, the concept of “user acceptance”. As Ghazizadeh [14] says “technology fundamentally changes a person’s role, making the system performance progressively dependent on the integrity of this relationship. In fact, automation will not achieve its potential if not properly adopted by users and seamlessly integrated into a new task structure”. Furthermore, Miranda et al. [24] talk about Internet of People (IoP). In fact, they reiterate that technology must be integrated into the users’ daily lives, which are right at the center of the system. They focus on the fact that IoT systems must be able to adapt to the user, taking people’s context into account and avoiding user intervention as much as possible. Similarly, Ashraf [2] talks about autonomy in the Internet of things, pointing out that in this context it is necessary to minimize user intervention.
Thus, the acceptance of a new technology seems to be the key point, which is not always obvious. It is not easy for users to understand how a complex technology like this reasons and works. Often it is not clear what it is able to do and how it does it.
So it is true that security, privacy, and trust work together to increase reliance on IoT systems. However, it is necessary to keep users in the center of this discussion. The reasons why the user may not grant high trust levels are the fears that (a) the task is not carried out in the expected way; (b) that it is not completed at all; or (c) even that some damage is produced. These issues become more and more complicated if we think that these devices can operate in a network that has a theoretically infinite number of nodes: we do not know the other devices’ goals or if they will be reliable. We get into a very complex system, difficult to understand and manage. In short, the overall picture of the functions that they perform is going to complicate a lot. As a whole, the devices have a computational power and a huge amount of data available; they could be able to identify solutions that we had not even imagined, which, however, must ensure that these systems will realize a state of the world coinciding with our expectation. What if our computer decides to shut down because we worked too much? Surely, we talk about tasks that have their usefulness, but it is not said that the concept of utility the devices possess coincides with ours. We need to identify the goals we are interested in delegating to these systems and, at the same time, that they will be able to understand these goals. To this purpose Kranz [19] studies a series of use cases in order to provide some guidelines for embedding interfaces into people’s daily lives. Economides [9] identifies a series of characteristics that an IoT system must possess in order to be accepted by users. However, he does not provide a clear methodology about how these characteristics should be estimated and computed. What we would like is on the one hand that the system adapts to the user, comparing the expectations of the latter with its estimations. On the other hand, we would like the user to adapt to the system, trying to accept increasing levels of its autonomy. Therefore, we start proposing a categorization of the devices’ tasks based on the autonomy. In order to operate, the devices must continuously estimate the level of autonomy that the user grants them. Doing so, the relationship between an IoT device and the user starts at a level of complexity that the user knows and can handle, moving eventually to higher levels if the user allows it, i.e., if the trust it has towards the device is sufficient. In all this it becomes fundamental to identify the levels of user trust. Trust therefore becomes a key concept.
Reference scenario
The introduction of IoT technologies enables enriching the system’s functionalities in many different environments. Given the extent of the potential applications, we intend to specify which scenario we are referring to. Our scenario is defined by: a set of users U = {u1, u2, . . . , u
k
}. a set of tasks T = {τ1, τ2, . . . , τ
l
} a set of devices D = {d1, d2, . . . , d
m
}. a set of features F = {f1, f2, . . . , f
n
}.
We consider the case in which a human user u i is located within a smart environment, i.e. a physical environment enriched by intelligent functionalities provided thanks to the presence of sensors, actuators and smart devices belonging to D. These devices have the goal to satisfy the user’s needs; not for receiving an income for their work, but because they have being designed to do so. By processing data coming from the environment, the devices offer, even on the basis of their autonomy, individually or collaboratively, a whole range of tasks T. There is a clear link between tasks and devices: from one side the tasks require specific features to be completed successfully, from the other side each device possesses some features that determines what it can/cannot do.
The user u i interfaces with the smart environment in two way: it asks for a specific task τ j or a device may proactively realize a task for him, either explicitly proposing it (or not) to u i .
The relationship between user and device is regulated by the concept of autonomy. The user grants each device a given level of autonomy, which will determine what a device can or cannot do. Given that the autonomy changes over time, the devices must be able to quantify this value at run time. Moreover, given that the context itself elicits the collaboration between smart devices, allowing the creation of complex services built on the basis of the simpler ones, it is fundamental to regulate even how a device should interact with the others. In general, the user u i will assign the task τ j to a device d h ; he will not care about whether d h will involve other devices. However, even the other devices’ behavior is subjected to autonomy’s limitation and d h has to consider this.
Practical examples of the situation we are picking out are: Smart houses, in which the mobility is reduced or completely absent. Usually the devices are always the same, i.e. the replacement over time is slow. Smart workplaces: they generally have more users than smart houses; even here the mobility is reduced. Smart cities: this is maybe the most interesting case, due to the high dynamicity of the network. There is a very high number of heterogeneous devices, moving continuously; new nodes could enter and old nodes could leave the network. Differently from the previous cases, given the enormous quantity of device, more device could provide the same functionalities, thus it is much more important to identify who makes them better.
Although we are interested in modeling a situation in which peer agents interact with the user, scenarios with central entities can be seen as particular cases of this model, whereby only one agent interfaces directly with the user and then, if necessary, takes care of allocating the tasks to other devices.
Trust, control and feedback
When we deal with collaborations and task delegation, regardless of whether it concerns humans or artificial machines, trust comes spontaneously into play.
As already stated, we analyze a situation in which the devices’ purpose is nothing but offering the best possible service to the users, so there are no utilitarian reasons, which could lead to betraying, lying or not providing the service. Anyway, even if there is no incentive to lies, this does not exclude them.
As it is well known in literature, there are many reasons why a device may provide untruthful information. Beside lies, a device may still be in good faith but it may fail in estimating the resources it will be able to exploit, it may suffer a failure or a temporary lack of resources which it has not considered when it committed to the service.
Moreover, the device are influenced by the autonomy the user grants, thus even if they possess some abilities, they may not be able to use all their potential. Being the autonomy a changeable parameter, it will dynamically define what a device can or cannot do. All of these is not linked to willingness, nor to its actual competence (strictly linked to its features), yet it affects a device’s performance. We model this as the device availability. Through the paper, we are not going to consider willingness. Moreover, we will not investigate competence and availability individually. Instead we will treat them as a unique dimension, which we refer to as efficiency.
Thus, here trust is used to model competence, how good a device/team is for providing a service. Nevertheless, the trust concept is also perfectly suited for modeling the motivational aspects, so it would be easily possible to extend the framework, introducing utilitarian or malicious devices.
Consider a situation in which an agent a x (trustor) needs a second agent a y (trustee) to perform a task for him and must decide whether or not to rely on him. The reasons why he would like to delegate that task can be different; in general, a x believes that delegating the task could have some utility. The cognitive agents in fact decide whether or not to rely on others to carry out their tasks on the basis of the expected utility and of the trust they have in who will perform those tasks. As for the utility, it must be more convenient for the trustor that someone else will carry out the task, otherwise he will do it by himself (if he can). The user may decide to rely on a device because he wants to save time or because he is not able to carry out the task. A device may not have all the necessary feature for doing a task (or part of it), then may ask another device to collaborate with it. The key point here is that when an agent a y , cognitive or not, performs a task for me, if a y is to some extent an autonomous agent, I do not know how a y intends to complete his task, nor if he will actually manage to do it.
In this frame, the concepts of trust and control intertwine in a very special way. In fact, the more we try to control, the less trust we have. Vice versa, when we trust we need less control, and we can allow greater autonomy. Thus, although control is an antagonist of trust, somehow it helps trust formation [5]. When, in fact, the level of trust is not enough for the trustor to delegate a task to the trustees, control helps to bridge this gap. The more I trust an agent a y , the more I will grant him autonomy to carry out actions. But if I do not trust a y enough, I need to exercise control mechanisms over his actions. For instance, it was shown [4] that when the users’ experience with autonomous systems involves completely losing control of the decisions, the trust they have in these systems decreases. It is then necessary to lead the user to gradually accept levels of ever-greater autonomy.
Control mechanisms are composed by two different meta-actions: To ensure that the task is successfully accomplished and that the desired goal is achieved. This can be done either by directly observing/checking the trustee’s action or by programming a trustee’s feedback on its work. To actively handle the possible unforeseen event (intervention).
The feedback must be provided before the operation ends, in order to be eventually able to modify that work. Otherwise, one can actively handle the possible unforeseen event (intervention). In this way, the feedback is a lighter form of control (less invasive), which may or may not result in the active involvement of the trustor. It has a fundamental role in overcoming the borderline cases in which the trust level would not be enough to delegate a task, but the trustor delegates it anyway thanks to this form of control. In the end, it can result in the definitive acceptance of the task (or in its rejection, and then results in trustor intervention and a consequent trust decrease).
Trust, a multilayered concept
Trust comes from different information sources. The first one is direct experience, in which the trustor a x evaluates the trustee a y exploiting the past interactions it had with a y . This approach has the advantage of using direct information; there is no intermediary (we are supposing that a x is able to evaluate a y ’s performance better than others). However, it requires a certain number of interactions to produce a proper evaluation and initially a x should trust a y without any clues (the cold start problem). Consider that this evaluation could depend on many different factors, and that a x is able to perceive their different contributions.
It is also possible to rely on second-hand information, exploiting recommendation [11] or reputation [8]. In this case, there is the advantage of having a ready to use evaluation, provided that a third agent a z in a x ’s social network knows a y and interacted with a y in the past. The disadvantage is that this evaluation introduces uncertainty due to the a z ’s ability and its benevolence; we need to trust a z as an evaluator.
Lastly, it is possible to use some mechanisms of knowledge generalization, such as the categories of belonging [12]. A category is a general set of agents— doctors, thieves, dogs, and so on—whose members have common characteristics, determining their behavior or their ability/willingness. If I am able to associate a y to a category and I know the average performance of the members belonging to that category concerning the specific task interesting me, I can exploit this evaluation to decide whether to trust a y . The advantage is that I can evaluate every node of my network, even if no one knows it. The disadvantage is that the level of uncertainty due to this method can be high, depending on the variability inside the category and its granularity. A practical example in the context of IoT is that I could believe that the devices produced by a given manufacturer are better than the others and then I could choose to delegate my task to them.
Since in this work we are not strictly interested in how to produce trust evaluations but in their practical applications, we will just rely on direct experience. This allows not introducing further uncertainty caused by the evaluation.
In this paper, trust is taken into account for two aspects. The first is that of autonomy. Similarly to [17] (in the cited work, the authors use a wheelchair, which in this case is not an IoT device, but an autonomous system endowed with smart functionalities and different autonomy levels.), where however authors are not working with IoT devices, tasks are grouped/categorized into several autonomy levels. A user, based on his personal availability, will assign a certain initial level of autonomy to a device. This level can positively or negatively change over time, depending on the interactions that the user has.
We need to define what a device can do, based on the current level of autonomy. It is worth noting that, even if we mainly focus on regulating actions, even the access to information should be similarly regulated. This is a primary privacy concern, related to the users’ awareness of the risk associated with the different autonomy levels.
Thus, the first contribution of this work is the identification and classification of the autonomy levels to which an IoT device can operate. Applying the concept of trust and control defined by [5], we defined 5 levels, numbered from 1 to 5.
Level1 requires operating according to the basic function; for example, a fridge will just keep things cool. This means that it is not going to communicate with other devices and it is not going beyond its basic task. Proceeding in the metaphor of the fridge, it cannot notice that something is missing; it does not even know what it contains.
Level2 allows communicating with other agents inside and outside the environment, but just in a passive way (i.e., giving information about the current temperature).
At level3 a device can autonomously carry out tasks, but without cooperating with other devices; again, thinking of a fridge, if a product needs a temperature below 5 degrees and another one above 7, it can autonomously decide which temperature to set, always keeping in mind that the main goal is to maximize the user’s utility.
Level4 grants the possibility to autonomously carry out tasks asking the cooperation of other devices. The cooperation is a critical element, as it involves problems like the partners’ choice, as well as recognition of merit and guilt. Again, thinking of the fridge, if it is not able to go below a certain temperature because it is hot in the house, it can ask the heating system to lower the temperature of the house. This needs a complex negotiation between two autonomous systems. They need to understand what the user priority is; this is not so easy to solve. Furthermore, it must also be considered that the systems in question must be able to communicate, using common protocols. This can happen if the devices use a standard of communication, enabling interoperability. Smart houses are valid examples of communication between different devices.
Level5, called over-help [10], gives the possibility of going beyond the user’s requests, proposing solutions that he could not even imagine: the same fridge could notice from our temperature that we have the fever, proceeding then to cancel the dinner with our friends and booking a medical examination. This type of interaction may be too pervasive.
It is easy to understand that these kinds of tasks require an increasing level of autonomy. The level 1 is the starting level. Basically, the device limits itself to elementary functions, the ones it is supposed to do. Beyond that, it is not certain that it is going to accept the next levels. A trust value is associated with each level i, with i going from 1 to 5, representing the user disposition towards the tasks of that level. The trust values for the autonomy are defined as real numbers in range [0,1].
These trust values are related to each other: the higher level “i+1” always has a trust value equal to or less than the previous one i. Moreover, we suppose that there is influence between them, so that when a device selects a task belonging to level i and this is accepted, both the trust value on level i and on the next level “i+1” will increase, according to the Formulas (1) and (2). Here the new autonomy trust value at level i, new _ η i , is computed as the sum of the old trust value η i plus an increment δ. Similarly, the new trust value on level "i+1", new _ ηi+1, is computed as the sum of the old trust value η i plus half of the increment δ. Of course, "i+1" exists only if i is smaller than 5; when i is equal to 5, Formula (2) is not taken into consideration.
When instead there is a trust decrease since the task is interrupted, even the trust in the following levels is decremented by ɛ. Formula (3) describes what happens to the autonomy trust value of level i, while Formula (4) shows what happen to the higher levels:
In Formula (4) ML is the index of the maximal level defined in the system. Here, in particular, it is equal to 5. The two variables increment and penalty are real values that can assume different values in range [0, 1]. According to [30] we chose to give a higher weight to negative outcomes than the positive ones, as trust is harder to gain than to lose.
What has been said so far concerns the aspect of autonomy. However, it is necessary to take into consideration that a device can fail when doing a task. Failures are due to multiple causes, both internal and external to the device itself. A device can fail because a sensor detected a wrong measurement, because it did not arrive to do the requested action in time, because it did something differently from what the user expected, or because a second partner device was wrong. All of this is modeled through the dimension called efficiency.
What matters to us in this case is that, for each specific task each device has a certain error probability. Although these values are expected to grow as the level increases, it is not said that is so; there may be errors that affect lower level tasks but not upper level tasks. It is therefore necessary to have a mechanism able to identify which tasks create problems.
Depending on the device’s performance, the trust values concerning efficiency for a specific task φ, defined as real numbers in range [0, 1], will be updated in a similar way to autonomy. Given that we are still dealing with trust and both efficiency and autonomy are modeled in the same way, for the sake of simplicity, we used the same parameters of the autonomy: with a positive interaction, the new trust value new _ φi,j,τ is computed as the sum of the old trust value φi,j,τ and the increment δ while, in case of failure, it is decreases by ɛ. The Formulas (5) and (6) describe this behavior:
Here φi,j,τ is the trust that i has on j concerning the task τ. Differently from the autonomy, we consider the efficiency trust can be defined at two different levels. The first one is the task-level, which is how much I trust that a device d is able to provide a task τ that I need, i.e. that it possesses all the necessary features to do it (or it is able to gather them). The second one is the feature-level, i.e. how much I trust that a device d possesses the feature f that I need, that d is able to provide f and it is willing to use it for me. This granularity is necessary for a device to create a team, allowing it to deal with individual features to provide a service. In the case of feature level efficiency trust, we consider the feature f and we compute it as:
For sake of simplicity, we consider that the user makes just use of efficiency trust at task level, while the device can use it also at feature level.
Of course, the trust at task level depends on the trust on the individual features, so it can be computed both using equations 5 and 6 or as the weighted mean of the features’ trust values. Note that this trust model allows the device estimating how trustworthy they are, according to the user. For simplicity, we suppose that the user actually uses this trust model, but it is not necessary. If the user’s trust evaluation is different (trust increase/decrease differently; there user is not willing to accept a higher level of autonomy), the model allows the device adapting to the situation.
The user
In the simulations, we have a single user u i dealing with a number of IoT devices. He uses them to pursue his own purposes, granting them just a given trust level, which limits their autonomy. After dealing with the device d h , u i will update his trust values concerning d h both for the efficiency and the autonomy. His decisions to accept, ask for a feedback, or refuse a task depend on two internal thresholds, thMin and ThMax. For simplicity, we consider them to be equal for all agents, but it is not necessary. In particular, when u i asks for feedback, it will be accepted with a given acceptance probability, a specific value characterizing the individual user. The trust values will be updated, increasing them with the constant δ, or decreasing them with ɛ.
The devices
There can be a variable number of devices in the world, which possess different features characterizing their ability to provide a specific service. The features a device offers could change over time: the battery level could decrease; the device could change geographical location (being more or less useful) and so on.
All of them possess two purposes. The first one is to pursue the user’s task and satisfying his need (even if he has not explicitly requested them). The second one consists of trying to increase the autonomy trust values, so that they can operate with a higher autonomy level, performing increasingly smart and complex functions for the user.
First of all, in order to understand at what levels they can work, they need to estimate the user’s trust values: the more trust there is on a level, the more likely it is that a task of that level will be accepted. Then they try to perform that task. If the device d h selected a task belonging to a sufficiently trusted level, then the task will be accepted; if it is not trusted enough it will be rejected. But there is an intermediate interval, halfway between acceptance and rejection. In this interval, if u i is not sure what to do, then it will ask the device for feedback, which will explain what it is doing. The feedback determines the task’s acceptance or its rejection (see Section 5.4 below).
If the task is accepted, then u i also checks d h ’s performance, which can be positive or negative. Each device has in fact a given error probability linked to specific levels. This probability generally increases with each level, as tasks with a greater autonomy usually imply a greater complexity, and so it is more difficult to get the result. But this is not always true. For example, some errors may occur at a specific level, but not in others. Resuming, the device is characterized by: the user’s trust estimation on the various levels; its efficiency estimation; error percentage on each level, an intrinsic characteristic of the device, which neither it nor the user can directly access it, they can just try to estimate it.
Task selection
Once a precise task classification has been provided, it is necessary to identify a methodology for correctly selecting a task itself. It is fundamental that the devices select tasks (a) to which the user is well disposed, therefore with a degree of autonomy that falls within the allowed limits; and (b) in which they can guarantee a certain level of performance. For the purpose of considering both these constraints, the devices compute what we call global trust vector, computing the average between the trust values of autonomy and efficiency. In order for a task to be selected, the relative trust value must be above a certain threshold. Generally, this threshold is equal to 0.5, but when a device is interrupted due to insufficient autonomy, this threshold is raised to 0.75 for a certain period. The tasks presented to the device are multiple and of various natures; it is not the same task performed with different autonomy. So it can happen that tasks of different levels are needed. In general, however, the devices try to perform sparingly the tasks that are not certain to be accepted by the user. The selection of the task level takes place in a probabilistic manner, with probability proportional to the overall trust estimated at that level. Let us make an example, to clarify this point. Suppose that the device d h estimates that the global trust values are 1 for level 1, 0.7 for level 2, and 0 for levels 3, 4, and 5. Given that only levels 1 and 2 exceed the threshold of 0.5, D can just select a task belonging to these two levels. In particular, proportionally to the trust levels, there is a 59% probability that it will select a task belonging to level 1, and a 41% probability that it will select a task belonging to level 2.
Acceptance, interruption, and feedback
Here we analyze how the user can react to task chosen by a device. As already mentioned, the user evaluates the trustworthiness of the different autonomy levels of the IoT devices, but he must also take into account the efficiency aspect. The user will check the two trust values and compare them with the thresholds. If the specific value is lower than the first acceptance threshold (thMin), the task is interrupted. If it is greater than the second acceptance threshold (ThMax), the task is accepted. However, a situation of uncertainty arises between the two thresholds. In this case, u i does not know whether to accept the task or not. At this point, u i asks for a feedback to the device d h , which is fundamental for the prosecution of the task. For a feedback on the autonomy, the device explains what it is doing, while for a feedback on the efficiency, the device clarifies the final result of the action it is performing. The feedback is a fundamental element of this complex system. Thanks to it, it is possible to overcome the limit situations that the devices need to face. Feedback will be accepted with a certain probability. In the case of autonomy, this probability p is an intrinsic characteristic of the user; it represents his willingness to accept a new task with greater autonomy. Regarding the feedback on the efficiency, it depends on the level of trust that the user has on the efficiency of the device. In particular, the probability c of accepting the feedback will increase linearly from 0% to thMin to 100% at ThMax.
The interaction user-device
In this section we focus on how users and devices interact, analyzing their behavior and the actions they can perform. Starting from the idle state, when a device performs a task τ the user checks its internal state, that is, its trust values for the autonomy ta and for the efficiency te, concerning the task τ. These values trigger the different actions described in Section 5.4: to accept the task; to refuse the task; to ask for feedback for the autonomy; to ask for feedback for the efficiency.
Concerning the feedback, it will involve the acceptance or the refusal of the task with a probability equal to p for the autonomy and c for the efficiency. Both these probabilities are described in Section 5.4.
Starting from the idle state, the device selects a task according to the user model, which is the estimation of the user’s internal state in terms of the trust values characterizing autonomy and efficiency. Once a task is selected, it starts executing it. If the user does not interfere, the task is completed. Otherwise it can be blocked or there can be a feedback request, which will result in the acceptance of the task or in its rejection. Notice that when the user stops a device, the device does not explicitly know if it is due to autonomy or efficiency, but it can deduce it, since it has an estimate of the user’s trust values. The trust update both for the user and the device is done according to the principles and formulas of Section 4.1.
The interaction device-device
Devices’ cooperation is fundamental in this environment, just as much as it is necessary to regulate it. Although u i is not directly involved, it is still necessary to respect the limit he impose. In general the user may not even be aware of the devices’ collaboration. He asks a device d h with a given level of autonomy to realize a specific task. Unless the user explicitly ask for a feedback, it is not relevant for him if d h works alone or with someone else. Starting from the autonomy level 4, a device may demand the collaboration of other devices. In general, we use a restrictive policy, so that d h cannot ask another device d q to carry out a task with a higher autonomy level of d h or of d q . Since the user may not be even aware of the sub allocation of a part of the task, he will just evaluate d h for the success/failure of the whole task. This means that d h is responsible for the task itself. Later it will evaluate the trustworthiness of its collaborator, as far as it concerns their part of the task.
Simulations
The simulations were realized using NetLogo [31], an agent-based framework. We aim to understand if the described algorithm works and actually leads to the user acceptance of new autonomy levels. Therefore, we investigate two sample scenarios that can happen while interacting with IoT systems, observing their evolution and the final level of autonomy achieved.
In the first one, we consider what happens when there is no error, assuming that the devices are always able to get the expected result. Since the devices’ efficiency will always be maximal, we will focus on the autonomy.
In the experiments, we considered that the execution of a task can be affected by errors: a sensor reporting wrong information, a partner device making an error, a different way to get the same result, or even a delay in getting the result can be considered by the user as an error. Here we focus on the relationship between autonomy and efficiency.
As we are interested in the final result of the model, we need to grant the system enough time to reach each of them. In order to do so, the experiments’ duration is 1000 runs; we will show the final trust values just after that period. Moreover, to eliminate the small differences randomly introduced in the individual experiments, we will show the average results among 100 equal setting simulations. In particular, we will report the average trust values that the user has (the values estimated for each device are aggregated into a single value) in autonomy and efficiency. For convenience, in the experiments we will indicate the values of trust or error in the various levels with the form [x1 x2 x3 x4 x5] in which the subscript stands for the level.
First experiment
The first experiment analyzes the case in which the devices make no error. In this situation, we just focus on the aspect of autonomy, while the efficiency plays a secondary role. Experimental setting: Number of devices: 10 Error probability: [0 0 0 0 0] ɛ = 0.1 δ = 0.05 User profile = (cautious, normal, open-minded) Feedback acceptance probability: 0%, 25%, 50%, 75%, 100% Duration: 1000 time units thMin = 0.3 ThMax = 0.6 Initial trust on efficiency:[0.5 0.5 0.5 0.5 0.5]
Before starting the discussion of the experiment, we discuss the choice of the simulation parameters, especially for the user. We did not investigate different values of penalty and increment (and the corresponding user-penalty and user-increment), but we made a few considerations for determining their values. First, they need to be sufficiently small to provide a stable trust evaluation, as high values would lead to an unstable evaluation, too dependent on the last experience. Second, since humans are more influenced by negative outcomes than positive outcomes [30], penalty and user-penalty should be respectively greater than increment and user-increment. Third, as the devices need to estimate the user’s trust values, it is very useful that their parameters coincide. A more complete solution would require that the devices estimate the user’s values at runtime. However, this is beyond the aims of the experiment. As for user profiles, these affect the initial levels of confidence in the autonomy of the devices. The cautious user is the most restrictive; its initial values are [1 0.75 0.5 0.25 0]. This means that at the beginning only the first 2 task levels can be executed. The normal user has slightly higher values: [1 1 0.75 0.5 0.25]. With this user it is possible to perform the first 3 task levels. The last type of user is the open-minded: [1 1 1 0.75 0.5]. Since this user is the most open towards the devices, it will be possible to immediately execute the first 4 levels of the task. We will focus on the cautious user, as it is the most restrictive. Then, if necessary, we will show the differences for the other users. We chose to set the initial efficiency trust values to 0.5, which represents an intermediate condition. The user does not possess any clues nor has an internal predisposition that could lead him to trust more or less a specific device on a specific level. Therefore, he needs to build experience to calibrate these values. Concerning the choice of thMin and ThMax, there is only the constraint that the first should be smaller than the second. We chose 0.3 and 0.6, respectively, in order to divide the trust degree in three intervals of similar size. In the below tables, we can see what happens to the user after the interaction with the devices. Each row represents the trust values that a user with a given percentage of feedback acceptance has on the five task levels. As we can see from the values of autonomy and efficiency (respectively Tables 1 and 2), in this situation the designated algorithm allows to reach the optimal trust levels.
User trust levels concerning autonomy when the devices do not make errors
User trust levels concerning autonomy when the devices do not make errors
User trust levels concerning efficiency when the devices do not make errors
This is just the ideal case, but it is also the proof that the whole mechanism works. The device can estimate the user’s trust values and they first try to adapt to them. After that, there is a continuous phase of adaptation, both for the devices and for the user: the devices continuously try to modify the user’s trust values. At the end, it will be possible to execute the tasks belonging to any level. Notice that the final results are independent of the percentage of feedback acceptance and the user profile. These parameters do not influence the final value, but the time needed to get it. Those that we saw are in fact the final results, after 1000 runs. We did not analyze the way the trust levels change during this time window. The feedback acceptance probability for the autonomy influences the speed at which these values are reached, so that a “more willing to innovate” user will reach those values first. For instance, Table 3 shows what happens in the first experiment after only 250 runs. Here we can see significant differences, due precisely to the fact that users with a lower feedback acceptance probability need more time to reach the final values. After a sufficiently long time, they all will converge to the same final value; the ending point is always the same.
User trust levels concerning autonomy after 250 runs, when the devices do not make errors and the user is cautious
In this second experiment, we consider the presence of errors. We made the assumption that error probability increases while the task level increases: starting with 0% at the initial level, as the device is supposed to perform its basic functions correctly, it is raised up to a maximum of 20% at the last level. This makes sense because the device is going to perform increasingly complex tasks; however it is not said that it works always this way, other types of error may occur. The experimental setting is the same of before, we just changed the error probability to [0 5 10 15 20]. Introducing errors, the trust in the devices’ efficiency decreases as the error increases, as shown in Table 4. As far as autonomy is concerned (Table 5), we would have expected it to reach maximum values, but it does not. Sometimes, in fact, errors happen repeatedly on level 5. If this occurs so many times to reduce confidence in the efficiency below the thMin threshold, the user will block all future execution attempts of that task level for the specific device. As it is no longer performed, its trust in autonomy will also remain low. Concerning the user profiles, they influence the final trust value in the autonomy. Since they start from slightly higher values, even at the end of the simulation they will reach higher values. For example, Table 6 shows the autonomy graphs when the user is open-minded.
User trust levels concerning efficiency when the devices’ error increases with the task level and the user is cautious
User trust levels concerning efficiency when the devices’ error increases with the task level and the user is cautious
User trust levels concerning autonomy when the devices’ error increases with the task level and the user is cautious
User trust levels concerning autonomy when the devices’ error increases with the task level and the user is open-minded
As already mentioned above, it is not said that the error increases with the levels. It could be independent. Different kinds of errors affect differently the device performance. In this second experiment, we simulate a malfunctioning sensor, compromising the low-level functionalities. Specifically, we introduce a very high error probability at level 1 and we check what happens. Concerning the experimental setting, again what we change is just the error probability to [50 5 10 15 20].
In this experiment we want to understand if a low level error affects somehow the upper levels. Table 8 shows that the user lowers the trust values in the devices for level 0, while the other levels are not affected by this decrease in performance. Therefore, the values in the other levels remain the same of the previous experiment. Table 7 shows that the values of autonomy are not affected by the error. Even in this case as in the previous experiment, an initial user’s trust values imply higher trust values for the autonomy.
User trust levels concerning autonomy when there is a high error rate at the lower level and the user is cautious
User trust levels concerning autonomy when there is a high error rate at the lower level and the user is cautious
User trust levels concerning efficiency when there is a high error rate at the lower level and the user is cautious
The experiments we proposed analyze three interesting situations, with the aim of verifying the behavior of the theorized model. The first experiment proves that in the absence of errors, and therefore in ideal conditions, it is possible to reach the maximum levels of autonomy and efficiency. This depends on the fact that in the model we considered the users have no constraint on their confidence towards the devices if they are shown to perform correctly. In other words, there is no implicit limitation impeding the increase of trust in such cases as the devices perform well; this is clearly expressed by the Formulas in Section 4.1, regulating the dynamics of trust. Of course, this ideal approach has been further extended, making it more realistic, considering that some users could have intrinsic limitations against a too strong autonomy of the devices. Then we analyzed the factors affecting the system, trying to understand what effects they have and if they represent a constraint for autonomy. The first factor is that of efficiency. It has a very strong effect, so in the presence of a high error rate, some tasks are no longer performed. In case of low-level tasks, there is no influence on the next levels. However, if the error were about the highest levels, this could also lead to the non-achievement of the highest levels of autonomy. Concerning the initial user profile, its relevance is due to the fact that, in the presence of error, a more open profile makes it possible to reach slightly higher levels of autonomy precisely because these values are higher at the beginning. It is important to underline that there are many more structural differences between the typologies of users we choose; these differences could be integrated in cognitive variables that could influence the outcome, reducing, with respect to the results shown, the acceptance of the system. Given the absence of real data, in this work we decided to model the different user profiles based only on the initial availability. However, we plan to integrate this aspect in future works. The last factor is the feedback acceptance probability for the autonomy, a characteristic of the specific user. As we have shown in the results (Table 3), this parameter influences the speed at which the corresponding final trust values are reached, so that a “more willing to innovate” user will reach those values first.
Conclusion
In this work, we propose a model for the users’ acceptance of IoT systems. While the current literature is working on their security and privacy aspects, very little has been said about the user’s point of view. This is actually a key topic, as even the most sophisticated technology needs to be accepted by the users, otherwise it simply will not be used. The model we proposed uses the concepts of trust and control, with particular reference to the feedback. Our first contribution is a precise classification of the tasks an IoT device can do according to the autonomy the user grants. We defined 5 levels of autonomy, depending on the functionalities a device has; the execution of a task belonging to a certain level assumes that it is also possible to execute (at least according to autonomy) the tasks of the previous levels. Based on this classification, we provided a theoretical framework for the device–user relationship, formalizing their interaction. It is in fact a complex interaction: on the one hand, the device must adapt to the user, on the other hand, it must ensure that the user adapts to it. The realized model perfectly responds to these needs. We proved this by the means of simulation, implementing the proposed model and showing that it works and it allows enhancing user’s trust on the devices and consequently the autonomy the devices have.
In a further step, we tested the model in the presence of incremental error, i.e. increasing with the complexity of the task. Of course, even if we did not consider them, there can be other kinds of error, such as hardware-related errors (for instance a non-functioning sensor or actuator) or errors due to the cooperation with other devices (wrong partner choice, wrong coordination, etc.).
The entire work provides some hints and interesting considerations about the user’s acceptance of IoT systems. Their designers should keep in mind this analysis in the design phase. Even if this results are encouraging, of course it will be necessary a further step to measure users’ acceptance of real systems.
It is worth noting that these results have been obtained focusing not on the specific characteristics of the device, intrinsic in its nature and bound to a specific domain, but on what it is authorized to do based on the autonomy granted to it, implying that these results are applicable to IoT systems in general, regardless of the domain.
Footnotes
Acknowledgments
This work is partially supported by the project CLARA— CLoud plAtform and smart underground imaging for natural Risk Assessment, funded by the Italian Ministry of Education, University and Research (MIUR-PON).