This document describes Use Cases and Requirements for the Web of Things.
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, but there still should be a single way how interactions with the overall building automation infrastructure are possible.
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 int this dataset. 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.
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.
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.
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.
In a factory, the automation function does not run on a large central system, but decision-making is shifted "downwards" towards the machine itself.
In order to introduce such a new function, the function can first be run supervised inside the central system and then shifted downwards, e.g. installed on a field device.
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.
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).
...
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:
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).
...
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.