The Web of Things (WoT) Interest Group (IG) is collecting concepts and technologies
to enable discovery and interoperability of Internet of Things (IoT) services on a
worldwide basis.
This document is used to collect IoT use cases from different domains for the Standardisation
work in the W3C WoT groups.
The domain use cases are dissaminated to identify so-called
building-blocks
that are common across the different domains as well as
non-functional requirements.
The identified
building blocks are inputs to the investigation and standardisation work.
The technology candidates for the respective
building blocks were moved into the
tech landscape document.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This collection of exemplary use cases is the result of discussion in the Web of Things Interest Group. The Web of Things Interest Group believes that Working Groups such as a potential The Web of Things Working Group or others will provide recommendations that simplify the application development and interoperabilty for the mentioned use cases. The Web of Things Interest Group may continue to discuss other areas of IoT that have not already been raised in this document, as well as refine the stated use cases and requirements.
This document was published by the Web of Things Interest Group as an Interest Group Note. If you wish to make comments regarding this document, please send them to public-wot-ig@w3.org ( subscribe, archives). All feedback is welcome.
Publication as an Interest Group Note does not imply endorsement by the W3C Membership.
This is a draft document and may be updated, replaced or obsoleted by other documents
at any time. It is inappropriate to cite this document as other than work in progress.
The disclosure obligations of the Participants of this group are described in the
charter.
Buildings often have a large variety of components such as Heating, Venting, and Air Conditioning (HVAC), lighting systems, and possibly more specialized systems such as support for reserving rooms electronically. Very often, these systems are not provided by a single supplier. Instead, landscapes of heterogeneous systems develop over time. Interoperability becomes a paramount challenge, as there should be a single way how interactions with the overall building automation infrastructure are possible. Furthermore, sensors, controllers, and actors of one system serving one specific use case can be useful for other use cases and can also enable new cross-domain applications and services to amplify comfort, security, and operational efficiency in smart buildings.
Possibly, building automation scenarios can have layered services, such for example when it comes to temperature sensing. While the basic functionality of the building automation system might only include to get information about the current temperature in a variety of places, there also might be a "temperature history" service. This service might allow more advanced features such as accessing the complete history of temperature measurements, and possible even more advanced functionalities such as queries in this dataset. By combining available data (e.g., weather forcast and occupancy of meeting rooms), room temperatures and future cooling/heating demand can be predicted to increase (e.g., an office building's) energy efficiency. Again, such an advanced service should be accessible in the same way as the more basic services, so that developers can access all these services in a uniform way.
Each employee in an office building specifies a preference profile (temperature, light setup, table height, ...). Due to his company badge or his smartphone the building can automatically influence the building automation system around him based on his current location and preference profile.
Besides an increase of comfort in general, personal profiles can also be used to assist people with special needs. For instance, in case of emergency, the acustic alarm sirens are insufficient for death people. Other mechanisms like flashing lights or mobile device notifications that are available in the person's proximity need to be used.
In case of several people in the same room (e.g. a meeting), a meditation is needed. This is also the case in other cross-influenced situations and if overall goals are set to be achieved, such as energy saving.
Joan has a heavy load of washing to do. She decides to run it over night to take advantage of the lower power prices. She loads the clothes into the washing machine and selects the economy operation mode. She has previously set her preferences with her home automation agent that is accessible on the Web from her phone, tablet, TV or laptop.
see http://www.w3.org/WoT/IG/wiki/Use_cases_across_application_domains#Smart_control_of_washing_machine
The physical user controls on the washing machine are deliberately simple, and designed to work in conjunction with the web based home automation agent. This agent has access to Joan’s electricity supplier and as is able to track the price charged by her supplier on her electricity plan as it changes according to demand across the city. The agent runs in the cloud, but is able to communicate through the firewall with devices in Joan’s home via her home hub. This was set up automatically when she first plugged the machine in. The washing machine has a very limited embedded controller. It suffices to run the desired washing and drying cycle, and has sensors that monitor its operation and enable components that are wearing out to be detected before they fail. Joan has agreed to share this data with the manufacturer as part of the warranty agreement. In return, she gets proactive scheduling of service visits at her convenience.
main: smart home / home automation / deferred operation
related: smart cities / smart grid / signaling with smart power devices
Thing registers: thing registers with service in the cloud
Configure data subscription: specific data field (e.g. for maintenance) is forwarded (e.g. to manufacturer)
Thing integration in web based agent
Life cycle of devices, services and applications
Discovery of devices
Installation process
Dealing with faults
Replacing devices
Replacing devices
Many households nowadays use one or more of Home Automation service, Demand-Response (DR) service or Securities and more. For DR subscription and operation, a home gateway device communicates with an aggregator to shed energy use on when asked. Home automation, typically also with a home gateway, enables cloud-based monitoring and control of home devices based-on pre-defined rules that perform actions based on conditions or triggers such as weather forecast or push on doorbells. Security services also install sensors and provide cloud-based control of security features such as arming/disarming and monitoring.
There is an increasing need to integrate those discrete services from different vendors harmoniously to increase the total benefit by orchestrating them.
see https://lists.w3.org/Archives/Public/public-wot-ig/2015Mar/0048.html
Clear separation of roles between home gateway through which to manage devices and sensors at home, and management platform that enables mashed-up, coordinated cloud-based services. Each device and sensor connects to home gateway through various technologies (e.g. Wi-Fi, Bluetooth, ZigBee, etc.).
Katherine prefer to living in comfortable condition. She has an air conditioner at home and has been using her smartphone to controlling it since a controller application on the smartphone can more precisely control based on her preference instead of using a remote controller that comes with. Recently she bought a home hub. Then now she can use another attentive feature that can turn-on the air conditioner from outside using the smartphone and the application a little bit before arriving at home to preparing more comfortable room temperature for her.
Requirements:
- An application on a smartphone can search devices possible to control both on local network and remote network.
- An application on a smartphone can understand the property of searched devices.
- An application on a smartphone can send commands without caring the network connection underneath.
Related Building Blocks:
- Abstracted discovery mechanism that applications can queries devices possible to use both locally and remotely.
- Abstracted device representation that applications can understand capabilities of devices to articulate a command to send.
- Abstraction APIs that applications can access devices with network agnostic.
Katherine is a frequent business traveler. She stays in a variety of different hotels in many cities and different countries. In each hotel room she is able to control the lighting, heating/air conditioning, locks, alarm clock, water temperature, and entertainment in her room. If someone knocks on the door she can see who's there from the TV or from her phone (a security camera is outside her door). Control is available from her mobile device, or she may be able to interact with the hotel room's services through an ambient device located in the room. It is important for user satisfaction for Katherine to get immediate access to these services when she checks in (without installing hotel-specific software), but it's also important that she not have access after she checks out. She doesn't have time to learn a new user interface for every hotel, or even every hotel chain, that she stays in, because she stays in so many different places.
The user should also be able to control the room remotely through her mobile device; for example, she would like to be able to warm up the room when she is within a half hour or so of arriving back from dinner. This would support energy savings because the room could be colder when no one is there. Similarly, geofencing could also be used to turn on the lights when she's approaching the room.
The user would also like to have her preferences made known when she checks in. For example, the room should automatically know her preferred room temperature, preferred units (metric vs. English), and her preferred language. However, her preferences may have to be overridden by the hotel (for example, if she prefers a temperature that is too high or too low, or if her preferred language is not available). In that case, she needs to be informed that her preferences can't be met and she should be offered alternatives.
Privacy is also important in this use case. For example, the user doesn't want it to be generally known whether or not she's in the room. Security is important for preventing unauthorized access to the room or its services.
The user sometimes also shares a hotel room with a colleague, in which case both occupants need to have access to the same capabilities.
see https://lists.w3.org/Archives/Public/public-wot-ig/2015Apr/0027.html
This use case describes a dynamic configuration where different users are coming and going into the same space. It terms of control it is very similar to a smart home, but the difference is that the occupant of the room changes on a very frequent basis.
Discovery is very important so that users' devices can be used to find the hotel room's services and their capabilities. It also points out the importance of:
Interoperabiltiy across vendors
Uniform user interface across hotels
Communication of user preferences between users' device and hotel.
Smart buildings
The hotel communicates with the room to allow/block access to control of a room as required when a guest checks in/checks out.
The security camera communicates with the phone and/or the TV so that the camera image can be displayed.
The user's mobile device communicates with the heating/AC to set preferred temperatures.
The user's mobile device communicates with the TV to set preferred languages and channels.
The user communicates to the alarm clock, TV, heating/AC and water to set alarm times, TV channels, and water temperature when she wants to change them.
How access to the hotel services are authorized (e.g. passcode, biometrics, smart room key).
How access is turned on/turned off for new and departing guests.
In companies like a large industry bakery you have storage facilities like silos to store production materials. In order to keep track of the amount of production material in the silos, level radar devices are used. The measurement data is collected by an order management system.
As soon as the production material falls below a certain threshold, the system sends an order to a delivery company.
In a factory, the automation function does not run on a large central system, but decision-making is increasingly decentralized, i.e., shifted "downwards" towards the machine or control panels on the shop flor. With the advent of the digitization, the demand for a flexible production in small batch sizes or the production of multi-variant mass products arises in many manufactoring industries. The production process can be adaptive if product memories specify the machining; appropriate paths along the production line can be discovered dynamically.
In order to introduce such a new automation function, the function can first be run supervised inside the central system and then shifted downwards, e.g. installed on a field device.
Manufacturing plants and process automation plants not only have to be monitored on-site but also from remote locations. That is for example to compare KPI (key performance indicators) of different manufacturing sites and optimization of the production processes and outputs based on the collected data, for diagnosis, remote service support or predictive maintenance.
For such a system you need a platform that collects the data from field level devices, from control level and also from applications on MES level. Applications can connect to the platform to retrieve the data for further processing (e.g., optimization algorithms). The open platform enables the connection between data points provided from devices/applications of different companies to applications from different parties (e.g., a software that provides trouble shooting information combined with online status information of devices in an optical head-mounted display).
Continuous condition monitoring of machines and production systems allow for understanding the current operational performance of a production system. Furthermore, by observing the deterioration of machines or analyzing the causes of defects, typical event patterns and causally determined correlations in more complex systems can be learned and used to predict future maintenance demand. Precise predictions require a large amount of high quality monitoring data in order to achieve the promised aims of reducing the percentage of unplanned maintenance and downtime. Many defects can be diagnosed, and sometimes fixed, remotely if the maintenance service provider accesses historical and live machine data. Furthermore, previous maintenance and repair reports provide useful knowledge to find a solution quickly.
An efficient maintenance strategy dispatches technicians according to the current maintenance demand, downtime probabilities, available resources, preferences of the machine operator, in conjunction with economic trade-offs. In particular, the dispatching for an optimal maintenance strategy needs to integrate the predicted maintenance demand with various other information sources like skills and experiences of available service technicians, information of installed machines and systems, availability of potentially useful tools and spare parts, time limits of forthcoming production orders, etc.
An industrial automation systems (IAS) needs to be managed throughout different phases of its lifecycle, e.g., development, engineering, operation, maintenance, optimization, and other phases. The lifecycle management is a challenging task due to various reasons. For instance, it is a task that involves various stakeholders (e.g., domain engineers, software engineers, system engineers, system installers etc.) and hence it is an error-prone task, it is often handled in a safety critical environment, it needs to be maintained over a longer timeframe (during which some of the stakeholders or parts of the system may not be available) and so forth.
Let us consider a use case scenario which, throughout the lifecycle management of an IAS, considers following tasks: Development of a new automation function, service or an app based on available resources and domain knowledge; Support for resource discovery, optimal selection and choreography of resources; Parametrization of resources, functions, services and apps; Support for adaptive services running in a dynamic environment (i.e., physical resources appear and disappear); Monitoring and diagnosis of resources, functions, services and apps; Optimization of automation workflows involving different resources and different lifecycle phases.
From these activities, as found in a typical lifecycle management of an IAS, one can derive following requirements:
A Virtual Power Plant (VPP) is an aggregation of Distributed Energy Resources (DERs), that can act as an entity on energy markets or as an ancillary service to grid operation.
The individual DERs often have a primary use on their own, with electric generation/consumption being a side-effect resp. secondary use. This results in negotiations/collaborations between many different parties e.g. such as the DER owner, the VPP operator, the grid operator and others.
Te process of charging an e-car diverts greatly from a simple pumping of gas. It involves several players apart from the obvious car, chargespot and car owner, such as electricity providers and clearing houses
An e-car and the chargespot negotiate different parameters affecting the charging process, such as voltages, currents, time it takes to charge etc., but also information like how the electricity will be payed for, how much was already transferred etc.
A device, its network environment, and the applications installed on the device, need to be managed. The relevant resources are typically represented in a hierarchical fashion (as modelled in the YANG schema language) and exchanged as collections or as subsets of a larger collection. Some of the resources can be so large that they seriously stress the runtime environment of the device (e.g., for firmware updates). Some of the subresources may appear and disappear dynamically (e.g., network prefixes). Retrieval and update of the resources may refer to non-contiguous subsets of a hierarchy (PATCH, non-contiguous GET). Traditional URI-paths may be too expensive for repeated transfer in requests.
Flood warning systems are often based on blanket reports from local authorities and environment agencies, which are based on, limited resources and a small number of expensive, professional sensors.
If John wants to determine if his property will be affected by water, it needs access to flooding information at a street level and understand how connected water streams might effect the water level near his property. Such process requires higher resolution data on the streams, groundwater and complex basins riddling cities and villages.
John is part of a community-based initiative where members provide access to water level data by radio connected low cost sensors in their properties. It is very important for John to understand the quality of the information it has access too in order to make better decisions about what flood defences to use.
Privacy is also am important factor as sensors could be deployed in areas of low-density population and John does not want that other people can infer what kind of flood damages his property might have ensued.
see https://lists.w3.org/Archives/Public/public-wot-ig/2015Apr/0031.html
Device installation: Members of the community need to install water-level monitoring sensors on their property;
Data transmission: Data from the sensors need to be reliably transmitted to cloud services;
Data transformation: Data streams need to be manipulated and transformed in real time;
Decision Making: Resulting data streams should be used for decision making (e.g. through visualisation tools or other applications);
Network Monitoring: Data quality indicators should be used for monitoring the sensor network.
main: smart cities / other utilities / monitoring water levels for flood warnings
Resource Description: In the system, the data has to be enriched with some meta-information (e.g. timestamp, location, data quality indicators, provenance, etc.).
Thing registration: sensors and gateways are registered with services in the cloud.
Data subscription: agents subscribe to data streams generated by devices in the sensor network or other external data sources.
Data transformation: agents transform incoming data streams and generate outgoing data streams.
Quality Assessment: Information quality indicators associated with things are used by the technical team to monitor the operation of the sensor network
Automated Decision Making: Automated decisions can be made based on the current status of things e.g. activate flood defences.
Lifecycle of devices, services and applications
Discovery of devices and related data sources
John is retired and lives alone in his own apartment. He has bad legs and there is a constant risk that he falls. If that happens he is not able to rise from the floor without help. In addition, John suffers from heart arrhythmias and diabetes.
Due to John's condition he needs remote monitoring by his healthcare provider. He therefore wears a wristband capable of continuously monitoring his heart rate and detect irregular heart rhythms as well as detecting a fall situation. A future version of the wristband will also be capable of non-invasive monitoring of his blood glucose level. The wristband communicates wirelessly with John's healthcare provider. This remote monitoring system could be seen as a complement to a normal home alarm system for elderly people with which old persons manually could call an emergency service. The differences are that the wristband system detects severe conditions automatically, which is needed if the old person is confused or gets unconscious, and also has the possibility to measure medical parameters such as heart rate and heart rhythm.
see https://lists.w3.org/Archives/Public/public-wot-ig/2015Mar/0057.html
When the system is in operation everything works automatic without any user interface. The remote monitoring application runs in a cloud server and can communicate with the wristband. A local router, situated for example in a Smartphone, may be needed to translate between a local communication method such as Bluetooth Low Energy and the mobile network or wifi, but at application level end-to-end security and communication through firewalls are achieved. The communication must be reliable and the power consumption in the wristband low to achieve long battery life.
User interaction is only required at system installation. The user, or another trusted person, e.g. a relative, health care personnel or personal assistant, has to use a web browser to log in to the remote monitoring application and the user has to approve that the application has access to his/her wristband using an existing authorize system, e.g. OAuth.
To provide service discovery for applications the wristband, during the system installation, is registered in a discovery service that contains a service description for the wristband. This service description states for example manufacturer, owner and the APIs to access the resources of the wristband.
main: Smart lifecare / Healthcare and medical / Remote patient monitoring and care
Registration and authorization: Registration of IoT device to make it discoverable and accessible by applications. Registration and authorization of applications to access resources on IoT devices.
User interface: User interface only for registration and authorization. Operation is "user interface less".
Security: End-to-end security cloud service - IoT device
Low vision, blindness, deafness and hearing loss does not provide any limitation for users during operation of the system as the system is UI-less. However, the system installation process requires operation of a normal web browser, which may require assistance for people with physical or mental limitations.
Life cycle of devices, services and applications
Dealing with faults
Replacing devices
Taking devices out of operation
Ebele is a nurse in a large medical district covering many villages. Today she is visiting Imani who has been complaining of weakness and chest pains. Ebele uses her mobile phone to consult the doctor who is a clinic in a town eighty miles away. The doctor asks her to perform an ECG on Imani. She attaches the electrodes to Imani's chest and plugs them into the remote ECG monitor. This streams the data in real time over the mobile network to the clinic where the doctor is based. The doctor examines the ECG and spots signs of arrythmia, and directs Ebele to put Imani on a course of Tambocor.
The remote ECG monitor has a multichannel signal processing board that combines the readings from the electrodes to generate a clean analog output. This is fed to the ADC in a microcontroller, which streams the digitised samples over the mobile network to a server in the clinic. The data is then forwarded to the doctor's terminal for analysis.
main: Smart lifecare / Healthcare and medical / Remote patient monitoring and care
This use case involves a means to model streams as a complex data type for the description language for "things". In this particular use case, the stream consists of 24 bit values at a sampling rate of 300 per second.
In loosely coupled systems, applications may encounter resources they have no prior knowledge about. Resource Description is a facility that allows resources to be described or describe themselves, so that applications can use those descriptions to learn about certain properties and/or capabilities of a resource. Resource descriptions on the highest abstraction level needs to provide two main facilities: identification of resources through some referencing mechanism, and description of resources through some data model.
The default interaction in most Web-based scenarios are pull interactions, where applications request information form servers. This pattern supports scalability very well, because servers do not need to keep track of clients. However, in some scenarios it may be advantageous for this interaction pattern to be reversed, with servers (i.e., the managing entities of resources) initiating an interaction for certain resource-based events. These push interactions require servers to keep track of clients (often referred to as "subscribers"), but on the other hand minimizes interactions when resource events are infrequent but should be noticed by clients as soon as possible.
For many interactions, it is necessary that peers agree on a shared data exchange format. There are various ways in which such a format can be defined, and in which agreement can be reached, but the general goal for all of these cases is that peers can reach agreement on which data exchange to use, and what it means to use this format. Depending on the type of data to be exchanged, different data exchange formats have different advantages and disadvantages, but generally speaking, the most important factor is that there is agreement on the representation of the data to be exchanged, and how to parse that into a model that is usable and useful for the application's goals.
For some systems, its of crucial importance to be able to manage a dynamic, amorphous collective (ensemble) of components/devices that dynamically appear and disappear, resp. are on- and offline.
This implies also a form of adding new components that does not involve high engineering effort.
The ability to discover single devices resp. components with certain capabilities or attributes or an ensemble of these is a pivotal point for applications that target an group that bis dynamically gathered.
In the WoT, there are cases of operation resp. automation that involve more than one single system owner, but rather are based on a collaboration between different stakeholder that influence or are influenced by the system/application.
A sandboxed runtime with a standardized API/service based abstraction layer to enable the execution of applications on things. Architecturally comparable to nowadays browsers, app runtimes and containers like J2EE, but specifically targeted at constrained devices.
A language that enables resources to be choreographed, parametrized, wired and invoked. The language also features a communication protocol which enables collaboration during these tasks (e.g., checks constraints when resources are combined).
keeping a history / digital twin of a physical object that serves as a proxy or avatar
...
Whenever a user interacts with a WoT system or also in many M2M cases a crucial acceptance factor is the time between the input and the reaction
A data surce resp. the owner of this data needs to be able to decide who is allowed to see what data and methods are needed to define and enforce this in a secure yet pragmatic way
In some Wot appications, the integrity and dependability of data needs to be provable. Ensuring that the data was not altered and is genuine is a common requirement of all systems operating in public networks
The mutual trust into the respective peer's identity is of high importance especially in systems and applications interacting with physical entites
...
when services interact with a plethora of clients, a distinction of diffenrent layers of information exchange is a well-known way to ensure interoperability.
this means a layering of the OSI application layer 7:
a transport (HTTP, CoAP, XMPP, MQTT...) will enable basic exchange and negiotin of formatted data
independent of a tranport, several interaction primitives (Request-response,Pub-sub, Message...) are possible
the transferred data is to be seperated into the representation (JSON, XML, EXI...) that is used to serialize a data structure (Schema, DTD ...)
This enables the communication of a resource to be implementation-independent
RDF is a standard model for data interchange on the Web. RDF has features that facilitate data merging even if the underlying schemas differ, and it specifically supports the evolution of schemas over time without requiring all the data consumers to be changed. RDF extends the linking structure of the Web to use URIs to name the relationship between things as well as the two ends of the link (this is usually referred to as a “triple”). Using this simple model, it allows structured and semi-structured data to be mixed, exposed, and shared across different applications. This linking structure forms a directed, labeled graph, where the edges represent the named link between two resources, represented by the graph nodes. This graph view is the easiest possible mental model for RDF and is often used in easy-to-understand visual explanations.
The Extensible Messaging and Presence Protocol (XMPP) is an application profile of the Extensible Markup Language (XML) that enables the near-real-time exchange of structured yet extensible data between any two or more network entities. This document defines XMPP's core protocol methods: setup and teardown of XML streams, channel encryption, authentication, error handling, and communication primitives for messaging, network availability ("presence"), and request-response interactions.
EXI is a very compact representation for the Extensible Markup Language (XML) Information Set that is intended to simultaneously optimize performance and the utilization of computational resources. The EXI format uses a hybrid approach drawn from the information and formal language theories, plus practical techniques verified by measurements, for entropy encoding XML information. Using a relatively simple algorithm, which is amenable to fast and compact implementation, and a small set of datatype representations, it reliably produces efficient encodings of XML event streams.