(such as [134]) shows that creating specialized operators running on Field Programmable Gate Array (FPGA) chips is beneficial. However, the support of such highly domain-specific operators means that DSPSs must cope with a heterogeneous system topology to exploit this potential. This results in a broad variety of participating computing nodes, which must be managed by the DSPS. The operators must also be matched with the available resources. Operators might only be deployed to compute nodes that satisfy their specific requirements.
2.4.2 Requirements to Data Processing
There are requirements that arise at the data processing level. Thus, the DSPS functionality in terms of data processing must be extensible with respect to application requirements. The following data processing requirements have been identified, these applications ask for:
II-A. Structured and unstructured data support: New application domains may introduce new kinds of data, such as images or video streams. A mixture of different data structures is of vital importance, as in the application scenario of the location-aware visualization application from Section 2.3.1. On the one hand static data originating from a database and dynamic data from sensors, e. g. modeled as relational data must be supported. On the other hand data formats represented by, e. g. a stream of images must also be sup-ported. Thus, particular care must be taken to avoid conflicts when combining operators at this level. This means that the DSPS must allow to implement new operators that go beyond those provided by state-of-the-art DSPSs.
II-B. Deployment and execution specifications: Applications as well as operators may im-pose certain constraints to the operator deployment and execution. E. g. operators may only be deployed on specific hardware, may require a certain amount of memory at runtime, or may even be allowed to be exclusively executed in a certain (secure) environ-ment, as for the smart factory example from Section 2.3.2. For this reason, the operator model of a data stream processing system must provide a way to describe operators with their respective deployment and runtime constraints. These constraints are defined by operator developers and application developers.
II-C. Exploiting mobile devices as data source and execution nodes: In the scenarios de-scribed in Section 2.3, mobile devices consume data but also provide data. E. g. for the location-aware visualization pipeline scenario from Section 2.3.1, the client receives a video stream of the rendered scene but must also provide the current position and view-ing direction to set the viewport correctly. In contrast, in the trajectory compression scenario from Section 2.3.3 the mobile device provides only data of the current position.
Furthermore, mobile devices might even be considered as potential compute nodes when processing data.
2.4 Resulting Requirements 55
2.4.3 Requirements to Security
Finally, requirements concerning the security of a system are important. In the following, two types of entities are distinguished: Subjects and objects. Subjects refer to entities, such as users of a system or a process running in a system. In contrast, objects are entities for which permissions are defined and usually representfiles, database entries, or executable code within a system. Generally speaking, subjects access objects. However, subjects might also be objects. Imagine a subject which wants to change the access conditions of another subject, such as, e. g. a user limiting the sharing of position to only family members (assuming subjects can be grouped according to their family membership). Information can be protected under the consideration of different protection goals, which leads to the so-called protection targets.
These protection targets influence the actual system design. We have identified the following classification, which is built out of three protection target classes. Each protection target class in turn consists of a variety of targets.
III-A. Access Control: Covers all targets that play an essential role for access control. Here a target that is of crucial importance is the data integrity, which ensures that objects cannot be changed uncontrollably and therefore guarantee that only subjects allowed to make changes will be able to access this data. Furthermore, the confidentiality of information must be ensured in order to hide information from subjects who may not be allowed to read this information. E. g. in the smart factory example from Section 2.3.2, the shift supervisor is allowed to see other data than the assembly-line worker.
Where the assembly-line worker is only allowed to see the status of the machine and the current work in progress the shift supervisor also sees work piece related information of the customer who ordered it.
III-B. Process Control: This covers all targets that influence the processing of data. It includes theacceptance of computation environments which are going to process the data. Since we assume a distributed environment, this protection target defines the computation nodes the data might be processed on. Beside this also dataextentis of importance. This protection target has influence on the data that is available at a time for data processing by the operators. By limiting the data extent a limited view of the current data window is provided. In this way, a control over the data quality can be achieved. E. g. for the example scenario described in Section 2.3.3, the extent directly influences the precision of the stored traces.
III-C. Granularity Control: This protection target class is a special case of the target confi-dentiality of informationandlimitation of data extentin the sense that it describes how fine-grained access and process conditions can be defined. Granularity covers targets which play a role in obfuscating the original data (object) in order to, e. g. prevent con-clusions to the subject the data originates from, with techniques such as anonymization and pseudonymization. Other techniques which belong to this protection target class are methods that add some fuzziness to data in order to hide detailed information on e. g. a current position, or aggregate a certain amount of data elements before delivering it to
subsequent operations. As seen from the LBS scenario from Section 2.3.4, friends should be able to know exactly where a user is whereas non-friend users should not. However, if the user wants to navigate to a certain destination, the more accurate the position information is the better the navigation is.
Besides the features mentioned above, also fundamental features such as the authentication of subjects and objects must be supported in order to prevent the abuse of objects. As shown with the LBS scenario, the correct authentication of subjects in the system is essential. This means that each subject must have a unique identity within the system. Thus the identity of subjects must be authenticated to avoid abuse of objects. Authentication covers all targets for the reliable identification of the relevant subjects and objects which are participating in the system. This also includes the authenticity of subjects and objects which must have the necessary rights to join the system as well as the actionliability, which assigns each action to a specific subject. To make these actions traceable a storage area to save the trace information must be provided.