For clarification, the following four non-trivial applications were considered: location-aware visualization pipeline in Section 2.3.1, management support in smart factories in Section 2.3.2, storing moving traces of moving objectsin Section 2.3.3, andlocation-based service application in Section 2.3.4. When presenting a scenario via figure, solid directed arrows indicate the streamed data which is forwarded by each operator. Dashed directed arrows indicate parameter updates, i. e. changes in the parametrization of operators.
2.3.1 Location-aware Visualization Pipeline
A complex data stream scenario that goes beyond the current state-of-the-art is an interactive and location-aware visualization application as depicted in Figure 2.2 (the resulting visualiza-tion is shown in Figure 2.1). In this example, the airflow in a room is simulated and visualized.
Objects moving in the room are tracked by the Position Tracker whereas the status of the windows is tracked by Window Tracker. The Fluid Solver simulates the velocity field, which depends on the objects tracked. TheEnvironment source delivers the static model data of the environment (in our case the buildings) that are to be displayed. The Calculate Stream Lines operator generates and calculates streamlines based on the velocityfield. To visualize the twist induced by the velocityfield, stream ribbons are calculated from the streamlines by the Calcu-late Stream Ribbons operator. The geometry obtained is rendered by theRendering operator, which produces image output. The rendering is usually not performed on the mobile client but on a remote server. The main reasons for this are the energy constraints of mobile devices and their typically insufficient processing power. This image output can be displayed on desktop
2.3 Example Scenarios 49
Figure 2.2:Visualization scenario realizing aflow visualization of airflows in buildings.
computers but can also be sent to Mobile Clientswhich do not have the capabilities to render complex scenarios. Preferably, the rendering step is executed on specialized graphics hardware (GPU) to get even better performance. User interaction, such as rotating and panning the scene, can be forwarded to the operators via parameter updates.
Thus, in order for the DSPS to support the location-aware visualization pipeline, it needs ade-quate integration mechanisms for its domain-specific operators and the respective constraints.
E. g. for the efficient execution of the domain-specific Rendering operator, the presence of a GPU is mandatory. Furthermore, different interaction patterns must be integrated, e. g. chang-ing the viewport for subsequent renderchang-ing steps and arbitrary data should be processable, rang-ing from structured data to unstructured and custom binary data as the rendered images.
2.3.2 Management Support in Smart Factories
A lot of influencing factors can cause disturbances in production processes of today’s smart factories [91]. Unsteadiness of the demand for a product, changes of orders of a customer, the delayed delivery of raw materials, failures of machines or the decreasing quality of the products require a quick adaptation of the production process. In order to perform such quick adaptation, it is necessary that the responsible persons, e. g. production managers or mainte-nance staff, can get information on the current state of the production facilities, failures or actions that are required at any time. Another topic of interest is the failure management
Figure 2.3:Management support in smart factories.
in such an environment. If a failure occurs during production, it is very important for staff members to get informed instantly of the problem, locate it fast, and get appropriate failure information. Thereby the responsible persons interact with the DSPS via interfaces. The inter-faces constitute sinks for data streams in a DSPS. Selections based on time, type and location can be implemented as a selection operator in a DSPS, thus Filtering data elements as they arrive, as shown in Figure 2.3, exploiting existing functionality. In such scenarios, the data stream system can also be used to propagate measured values from the sensors to a history server, making the data available for retrospective failure analysis. This step is not shown in Figure 2.3 but is comparable to the one depicted in Figure 2.4.
Data originating from production facilities often are a business secret of the company own-ing the factory. Thus it is important that applications or application developers can restrict the set of nodes for data processing to nodes owned or controlled by the company or at least to nodes the company trusts. Furthermore, the company is interested in restricting and con-trolling the actual access to this data only to individuals who are entitled. This means, data processing and access should satisfy certain policies, which are defined by the respective data owners or are even established in law.
2.3.3 Storing Moving Object Traces
With the increasing use of sensor technology, the compression of sensor data streams is getting more and more important to reduce both the costs of further processing as well as the data volume for persistent storage. An example scenario is depicted in Figure 2.4. A GPS receiver (Mobile Device with GPS Sensor) produces a stream of position updates, which is first reduced to positions within a given area (Selectionoperator ). The resulting stream is partitioned into windows by thePartitionoperator which forms the input for theCompression
2.3 Example Scenarios 51
Figure 2.4:Storing of moving objects’ traces.
operator. The compressed position information can be stored in a positionHistory Server for later analysis or can be further processed by subsequent operators (denoted by the boxFurther Processing).
This approach allows moving the generic part of the functionality out of the compression operator and implementing it as an additional operator, i. e. Selection and Window. This in-creases the performance, as the different operators can be deployed on different nodes and executed in parallel. Furthermore, this enhances reusability of the generic parts [70]. This way, on one side new applications benefit from existing functionality and on the other side future ones will also benefit from functionality integrated before. The DSPS grows with the applica-tion requirements. An addiapplica-tional incentive for integraapplica-tion is the possibility of distributing the actual processing arbitrarily across participating nodes.
2.3.4 Location-based Service Application
The proliferation of mobile devices has favored the development and provisioning of so-called location based service (LBS). LBS offer a higher service such as a navigation service of an information portal depending on the user’s current position. In this scenario, we describe a LBS namedSquebber. Squebber manages virtual messages which have been placed by users.
The messages can have an arbitrary content such as an invitation to some happening nearby.
Squebber users have a user space which stores personal information, such as the favorite music band or favorite food. Squebber reveals potential friendship among users according to common interests. The Squebber scenario is depicted in Figure 2.5. Squebber users can add messages for their friends and attach them to a certain position, e. g. at the user’s favorite spot. These messages are updated in the Squebber Source. Users can set the privacy of their position information and set the Filtering accordingly. Friends are allowed to see exactly where a
Figure 2.5: Location-based service scenario realizing the notification and navigation system
’Squebber’.
certain user is, facilitating spontaneous meetings. Other users might only be allowed to know the administrative district a certain user currently is in.
Once a user enters a certain area nearby some message which has been placed by his/her friend, a notification with the message content pops up in the mobile device. Such a notification might be an invitation to a birthday party. The friend now may accept the invitation and want to know how to get there. For this purpose Squebber creates a dedicated Navigationfor that friend and gets him to the place where the birthday party is usingenvironmental data, which isrenderedand then sent to themobile device.
This scenario illustrates that data providers need to define fine-grained access to data. Au-thentication of users is necessary to effectively restrict the access to data. Thereby, the user wants to adjust the quality of data he owns, e. g. position data, depending on the status of other users. If userAis defined as being a friend of userB,Amay know the exact position ofB.
The scenario also shows that dedicated services must be integrated—in our scenario the LBS service called Squebber. The service represents the interface for applications to interact with.
The service provides dedicated querying functionalities and generates SP graphs which are then executed. Therefore, the service itself interacts with other services present in the DSPS, such as an execution environment for SP graph execution. This way a tight integration with the other DSPS components is achieved.