The roles of the owner of an IoT device, expressed in UML

Internet of Things 2016/10/20

In a previous blog post we mentioned the different roles of the consumer owning an IoT device. In this article we will try to illustrate these roles in UML Use Case diagrams. The Use Case diagram is one of the several types of models that are part of the Unified Modeling Language (see wikipedia). These are used to describe the interactions of actors with a piece of software.

We will start with the most basic model. An actor (the consumer) uses a service (via an internet connection). This service is provided by —you guessed it— a service provider.

uml diagram

Pretty basic, even if you are not into UML.

The next step we add the fact that the service depends on data provided by the consumer. He now has two roles: that of the user of the service and that of the provider of data. In the Use Case diagram we show this by adding the role above the icon of each actor.

uml diagram

The role ‘consumer’

For someone who is used to talk about services in a software context, a little confusion creeps in. The label ‘consumer’ in an economical/marketing context is quite clear. It is used for individual people purchasing goods. In the world of digital services, the label ‘consumer’ is used in a more generic way. In this case it is used for any object (usually some kind of software) that uses the output of a service. Since we somewhat blend these two meanings we will now use the name “John Doe” for the individual that uses services in the Internet of Things. One of his roles is <<service consumer>>.

Back to the diagrams. The data provided by the customer (now identified as “John Doe”) is stored and processed by the Service. These are two separate activities, so we model the service as a group:

uml diagram

We now have a basic model of a generic service that is provided over the internet by a service provider, that depends on data provided by the end user.

Data processing

We’ll add one additional element. In the previous diagram John Doe uses ‘data processing’. While technically correct, an average John Doe is not likely attracted to use ‘data processing’. In business manegement lingo, the service provides ‘added value’ to John Doe; something (not strictly defined) that he recognises as having value for him.

uml diagram

Paying for the service

Well, you apparently are still with us. Up to this point things have been straight forward. Now we add somthing a little complicating. No service can exisist on it’s own. Providing a service comes at a cost. In the context of digital services and the Internet of Things this at least requires computer equipment and network connections. So we factor in than John Doe pays the Service Provider for delivering the service.

uml diagram

Sidestep: paying for a free service?

Now you may object: I’m using quite a lot of web applications that I do not have to pay for. Say Google, Twitter, Facebook, you name ‘em. So why adding this last step? Well, There is a lot to say about ‘free’ services. That is subject for another post (or even a series). But let me assure you: you are actually paying for these services, one way or another. It might not be by actually transfering money (as with subscription based services), but you are generating value for the service provider while using the service:

  1. Your usage of the services adds to the momentum and userbase for the service provider´s paid services which cover for the cost of the free services as well.
  2. You generate content you license to the provider (this happens more often than you think; read the fine print in the end user agreements or whatever fancy name they gave these legal statements).
  3. You allow the service provider to use your data to build profiles that it will monetize to its own discretion, i.e. targeted advertising. This case is covered by the saying “if you don´t pay f or the product, you are the product”. Usually this involves Personally Identifiable Information (PII for short).

This reasoning implies that we need to add another role for our dear John Doe: the data subject

uml diagram

Next: How the data is generated

We have described a model for a generic service that is using data provided by the consumer, John Doe. This model can be applied to many web applications. The data is usually generated interactively by the user via the application’s web interface, from another application using a published API or by means of an app on a mobile device. But what we call the ‘Internet of Things’ extends this model. Human interaction is replaced by smart devices that autonomously generate data.

The device

We will first focus on the device and leave the service out (for now).

uml diagram

Again a very basic start, but not for long.

Sidestep: The device and it’s software a.k.a. firmware

All devices in the Internet of Things are built as a combination of hardware and software. The time that his software was ‘burned’ into the hardware and could only be changed by physically interacting with the hardware has long gone by. The original EPROMs could only be reprogrammed after erasing them by exposing the hardware to strong ultraviolet light. The introduction of EEPROMs allowed electronic equipment to be reprogrammed electronically. Now nearly all devices have substantial amounts of non-volatile memory that holds the software that control the device’s functions. This software can be usually be replaced remotely; the process is called ‘flashing’, named after the type of memory involved.

The maintenance burden

Every device man has created requires maintenance. It’s the law. Not a legal one, but a law of nature. The second law of thermodynamics to be precise. Everything in the universe tends to ‘a state of maximum entropy’, which is a physics scholar’s lingo for ‘chaos’. We all experience this daily: everything eventually breaks in parts. If you wait long enough, these parts break into smaller and smaller chunks, until only atoms are left. At least, that’s the simplified version of the theory.

OK, you’ll have to wait a veeeeeery long time before your device turns into dust, but you get the picture. Anything man creates will degrade over time. Ignore your housecleaning chores long enough and your furniture will get covered with dust. We all have experience with electronic devices getting to behave erratic or not at all. We can’t prevent this degradation but we can (try to) postpone it by regular maintenance. Therefore our cars (mostly) get regular oil changes and while the tires evetually wear out we try to keep them balanced and sufficiently inflated.

This maintenance burden comes with the ownership of any device. For a device in the world of IoT this burden comes in two areas: firmware and configuration. Firmware is actually just software, but tightly coupled to the hardware. Firmware is usually not intended to be installed or modified by the owner of the device as we are used to with our desktops and laptops. Depending of the functionality it has configuration settings that can be changed by the owner or user of the ‘thing’. Configuration requires at least a basic understanding of the usage of the device and can be done wrong.

In our diagram we have to add the same actor John Doe a second time, but now in his new role of “device maintainer”:

uml diagram

As most of us know by now, software is rarely flawless. See this link for some horror stories. Updating the operating system of our computers has become an annoying but unavoidable part of our digital lives. The same is (or better: should be) true for the semi-autonomous devices in the Internet of Things. One major problem is that software flaws or bugs are not always repaired. Once a device is sold, there is not much of an incentive for a device maker to maintain its software beyond the period the devices are actually being sold. Yet, in our diagram we need to add the maintanance of the device. Someone at least has to provide updated software to users of these devices.

So again we need a new role: the “firmware supplier”. Usually this role is performed by the IoT device supplier.

uml diagram

The whole picture

Now it is time to combine the two diagrams we constructed:

uml diagram


We just created a diagram showing the different roles involved in the use of a ‘thing’ in the Internet of Things. A device that gathers data about someone and uses a service to process the data for the owner into something that he percieves as valuable. What at first observation appears to be very simple, evolves into a model in which John Doe performs no less than five different roles. And poor John thought he had only bought himself a ‘thing’…

Related content

Tags: IoT UML