Jan 29, 2016

Anatomy of an Internet of Things Use Case

Use cases are an effective tool to describe how a solution concept will function to meet a user requirement and produce the desired outcomes. These days, Internet of Things (or IoT) use cases are everywhere, created to describe applications in different domains such as health care, retail, energy, logistics, transportation, cities and so on.

While there are numerous IoT use cases propagated everywhere, one wonders sometimes if various definitions are getting mixed up. When do RFID tracking solution or a personal fitness sensor become an IoT solution? What are the essential requirements of an IoT solution architecture?  And conversely, what user requirements does an IoT solution fulfil?

This article tries to understand the what constitutes an IoT use case.

The poster below is a lengthy use case diagram using Unified Modelling Language (or UML) to illustrate a generic IoT use case. The domain in this example is a smart home.  
A smart home device use case for Internet of Things (IoT)


For those not familiar with the UML notification, a use case diagram is a visual model used to develop business requirements. The diagram consists of actors (humans, systems) and use cases which are actions taken in response to input from actors. A thorough use case in requirement analysis consists of stakeholders, actions, responses, conditions, extensions (additional steps based on conditions), inclusions and so on.

For purposes of this discussion, the use case diagram is fairly straightforward consisting of actors and high level use cases under scope of an actor. Further this is a so called “happy path”, meaning an ideal world where every actor has a specific role, co-operates with one another, all connections and data are secure, and nothing goes wrong. Like a good use case, the description is non-technical and does not depict any system or technology.

And as a concluding disclaimer, this depiction is a conceptual representation only showing the actors that would need to come together to meet requirements of an IoT solution.  The goal is to understand through a use case model, the scope and boundaries of an IoT application and those of various components involved.  

Moving on to the example, the diagram shows a use case blueprint for a smart home. Instead of a single device, this illustration depicts a group of diverse appliances, which operate on a single home network. These devices are able to interface with a central application or controller that can manage them which is more a typical scenario (there is a proliferation of apps that are trying to solve the basket of remotes problem in consumer IoT by managing many home appliances through a single interface).

As the diagram shows, five actors interact with one another in the solution. The main (in true use case world only actor) is the human end user who installs and operates the solution to meet their specific requirement (dim lights, turn on heating, open doors, make coffee etc.). The other four are discrete constituent systems that deliver separate capabilities. 

Location is a key factor in IoT. The physical pervasive devices have a geo-location and a local network (or home bus) in proximity. The remaining actors – cloud, app and human owner/operator are location agnostic and can be located anywhere and connected via the Internet. 

Let us take a closer look at the different actors and their respective use cases.

Smart Device

The smart device provides the actual function with added intelligence for automation and learning. The device takes action when an input is received (e.g. turn lights on) or triggers an event (such as a door sensor signalling attempt to force entry). 

Next, the device has to report this information. It does so by discovering a local router which can receive and send messages by a short range wireless protocol such as Bluetooth, Wi-Fi or ZigBee. The smart device is earlier on boarded on the local network and it identifies and establishes a connection. 

An important factor required for meaningful communication is semantics which means there is some object level identification (device signalling it is a light bulb and not a thermostat) and thereby a context to the information sent.  A semantic model comes into play so that the message is given in its correct context e.g. temperature range for a fridge has different meaning from that of a thermostat, so it is important that the source is also known.

Finally, the smart device also listens to and responds to feedback and takes the necessary action (e.g. dim lights, heat on, lock door).

 Local Network 

A short range localized network is used to detect signal and data from multiple devices and route it, similar to an air traffic controller. This can be the home Wi-Fi router, device router or in some cases, if multiple client appliances belong to the same collaborative network (such as the AllJoynTM router service), a separate router which connects client devices on a bus and directs information via a single channel. The router then connects to the Internet gateway and connects to the cloud (via wired broadband, wireless 4G LTE etc.).

App

Apps refer to mobile apps installable on different platforms or web applications and can thus be accessed from anywhere. The application or app presents a user interface enabling remote management of connected devices. Apps are used to configure or on board a device and give it its virtual ‘avatar’ on installation. Apps provide a notifications and deliver dashboards on insights, with an underlying design to provide an intuitive and seamless user experience. 

Cloud (or IoT platform in cloud)

The cloud hosts the IoT platform that manages and acts on the digital inputs. The IoT platform in the cloud delivers core computing and storage capabilities. It manages the user accounts and ownership of information and stores data, configuration and preferences. Device information received can be integrated or analyzed with aggregated information from external sources (weather updates, emergency notifications, energy consumption). The cloud platform performs processing and analytics to transform machine communications into actionable and meaningful insights. It then presents this information to different channels such as mobile apps as per user preferences.

End User

The end user is the human actor who is using the connected ecosystem to meet their person(alized) requirements. In this diagram the human role is given a system like interpretation, simply to depict where human interaction/intervention is needed. As shown, a human (possibly a robot butler in the not too distant future) sets-up the various connected components and once this is done, manages everything remotely. 

Of course real life is slightly more complex. 

In Summary

A good approach is to define the use case the way it was intended in UML i.e. to elicit user needs and expectations of how a system would behave. This can be applied to potential requirements for consumers and industry. For example, what are the situations today in healthcare where it would be imperative to get information in real time, over a localized network (e.g. bio-hazard areas)? What kind of analytics can be produced (e.g. traffic patterns based on weather or public events)? Where is location an imperative and where it is not. 


By connecting these requirements, an IoT application should emerge as the solution.

No comments:

Post a Comment