-Considering the Internet of Things in production To consider privacy in systems design, Hoepman et al. processes, the human factor and aspects such as data protection [6], [7] introduce and discuss eight privacy design strategies: and data transparency are often ignored. However, collecting, minimize, hide, separate, abstract, inform, control, enforce and isntortihnigs adnodmparionc.esTsihnigs dinactaluidsegsoidnagtatofbroema ssteannsdoarrsd, pmraocchedinuerse, demonstrate. These design strategies have already been taken and processes as well as individual data about people. Recent into account when discussing our ideas for a privacy model approaches such as assistive systems for human-computer and and an according system architecture in [8]. This paper goes a human-machine interaction need more personal data than ever step further and discusses them in relation with model- driven before to provide purposeful, tailored support. For MDE ap- engineering (MDE). lpervoeal.chTehsisit piaspiemrpdoirstcaunstsetso acownsaiydetro pcrrievaatcey parlirveaacdyy-pornesemrvoidnegl We believe that MDE and model-based software engineering IoT systems using an MDE approach to support privacy and (MBSE) can well help to incorporate privacy considerations data transparency. We show the relevance and application on a at model level. It can provide means to support the aforemenuse case from industrial production processes. Additionally, we tioned privacy design strategies. discuss abilities for practical realization and its limitation. Research question. These considerations lead us to the folpriIsnedeIxnfToerrmmast-ionDoSmyasitne-mSsp,ecIifincforLmanatgiuoangePs,orGtaelns,eraIntetdernEentteorf- lowing research question: How is it possible to include privacy Things, Model-Based Software Engineering Privacy-By-Design, considerations in the MDE development process already on Privacy Modeling model level? Contribution. The approach presented in this paper uses I. INTRODUCTION MDE tools and frameworks together with a set of domain specific languages (DSLs) to create an Enterprise Information Motivation and research gap. Research on the digitization System (EIS) considering privacy- preservation and provide of work processes for the production of the future is currently users and data providers with the relevant information to focusing strongly on technical solutions, such as the interfaces make informed decisions about their data use. We show a between software and devices (cyber-physical systems), the possible DSL model structure including domain models, a recognition of work steps and processes with sensors, mathe- privacy model and possible instantiations as well as relevant matical evaluations of the collected data and model-based sys- aspects which have to be considered for the system design, tems engineering [1], [2]. However, the human factor, both as e.g., privacy checkpoints. a working person and as an individual, is often not sufficiently In previous work [8], we have already presented a concept taken into account in these considerations. Human actions for user-centered privacy-preserving process mining systems can influence processes both positively and negatively and are design for IoT. This paper goes a step further and discusses therefore indispensable in an integrated view of production the inclusion of privacy considerations for an MDE approach processes and systems. The rise of wearable technologies and appropriate tooling. makes it possible to equip them with miniaturized sensors [3]. The MDE tooling we use in our example for a realIn order to assist people in the execution of their work ization are MontiCore [9] and MontiGEM [10]. MontiCore tasks, e.g. by means of body-hugging assistance systems by is a workbench for modeling language development which using motion capture systems for the markerless acquisition supports the agile and compositional development of DSLs. of postures to support an ergonomic analysis and improved MontiGEM, the Generator for Enterprise Management, is ergonomic intervention process [4] in a context- and target- based on MontiCore and uses (1) a set of models which are group-specific way, or by providing them means to learn about (2) parsed and transformed using a template engine towards work tasks, e.g., by using smart glasses [5], individual data (3) the target, namely output files in the target language. As a will have to be collected, processed and stored. However, result, MontiGEM creates an information system out of class this development goes hand in hand with questions about the diagrams and graphical interface models. informational self-determination, the security of data collected Overview. The next section discusses the term privacy as well as data protection and transparency. and general concepts for privacy-preserving systems design. Copyright ©2019 for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
Section III presents a use case from the IoT domain, namely a production process and shows its representation in a domain specific data model. Section IV shows our idea on how to combine privacy-preserving IoT systems and MDE approaches. We show an exemplary system architecture and relevant privacy checkpoints (PrC), the needed privacy model to support the execution of the privacy checkpoints, concrete examples for a purpose tree and the privacy policies (PPs) including privacy policy rules (PPRs) and the description on how to compare PPs and make the decision if data should be provided after a request or not. Section V discusses our approach in comparison to other approaches, weaknesses and limitations of it and advantages on using it. The last section summarizes and concludes our paper.
II. PRIVACY AND PRIVACY-PRESERVING SYSTEM DESIGN
The term privacy is related to informal self-determination,
which means the ability to decide what information about a
person is passed on [
To ensure data privacy, security provides the needed
foundations as it preserves the confidentiality, integrity and
availability of information and supports the authenticity, accountability,
non-repudiation and reliability [
To trust a person or system and in a next step to share
date with them, it depends on several factors such as past
interactions, what relationship exists to each other, similar
personality attributes such as interests or the sensitive nature
of the data we are sharing at that moment in time [
Our understanding of data sovereignty is related with the
personal rights of the people from whom the data originate
[
It is important to comply with privacy regulations such as
the Europe’s General Data Protection Regulation (EU GDPR).
Due to the EU GDPR[
To take privacy in systems design into account, Hoepman
et al. [
Regarding IoT, privacy became relevant with the massive
deployment of sensors in various environments (see section V).
It is possible to collect data and information about people and
to use analytic tools to profile users and identify them even
from anonymized data [
When investigating IoT in production processes, humans are often not taken into account as much as necessary. Our use case shows examples where it is important to consider human privacy concerns when collecting, storing and processing data in such processes. Moreover, we show an excerpt of the domain model including data needed for our running example. Please remark that our approach can be applied onto other use cases as well, as the domain information is well encapsulated.
Fig. 1 shows one station of a manufacturing area. There, several operators and robots collaborate in the production process. We use an IoT box as product to exemplary describe the process. The process steps for the IoT box assembly are: put the lower part of its case on the conveyor belt, assemble the different components such as the USB-port, serial ports, a WiFi and bluetooth module and HDMI port, put the upper part on top, test the functionality of the box and lift it off the assembly line into the transport boxes which are moved to the next production line for shipping.
There are several operators included in this process which
are wearing (1) smart glasses and (2) smart watches and are
using (2) smartphones and (3) tablets. All of these devices
are able to collect data about the usage and location in the
manufacturing area. Moreover, health data could be processed
for different purposes, e.g., to detect physical and mental
stress [
The plastic parts of the product (4) include RFID chips which make it possible to track them during the assembly 10 7
4 6 7 process. The assembly line itself (6) and involved machines such as the one for functionality testing (5) trace the product to recognize in which assembly step the process is. The robots (7) mainly support the lift onto and off process steps and (8) the transportation of needed resources and the final product in the transport boxes (9). These could be again tracked using RFID technology. Moreover, information portals (10) could provide the relevant information needs. Mobile and smart devices (1)(3) could provide this information as well.
Starting with this real life scenario, we create a domain model including relevant context information and data collected in various ways. Clearly, MDE approaches need domain information to create the database and persistence layer.
Considering the use case in Fig. 1, we create the domain
model including all relevant persons, their abilities, machines,
resources, processes and locations as well as attributes for
handling sensor data. As suggested in [
For the personal and social context employees, relationships between persons, their abilities and other personal data is relevant. There exists the general concept Person including information such as the name and the postal address. For Employees it might be relevant to have their birthday and employment dates. Operators (line 12) and other user groups can inherit from this concept. Operators have again specific attributes such as their shoe size to be able to provide them the right safety shoes or their position in the company.
For assistance purposes HealthData (lines 17-23) is needed, e.g., the heart rate, blood pressure or current stress level. For ergonomic analyzes the SkeletonModel including joints and relations in-between them is relevant as well. This data could be collected via smart devices and depth cameras.
CD4A..
association [*] Ability -> (type) AbilityType [
ZonedDateTime employmentStart; <Optional> ZonedDateTime employmentEnd;
ZonedDateTime birthday; class Operator extends Employee { long shoeSize;
String gpsPosition; class HealthData { int heartRate; String bloodPressure; /String stressLevel; /List<String> ergonomicProblems;
ZonedDateTime timestamp;
Listing 1: Data model in CD4A notation (excerpt) 58 59 60 61 62 63 64 65 66 67 68 69 70 71 }
Every operator has certain Abilities (lines 25-27). There are different AbilityTypes, such as the ability to control a certain machine type, do a specific process step, having a certain driving license, a specific certificate or further education. With this knowledge it is possible to know what person to place on which position in the company. The AbilityLevel (lines 31-35) defines the concrete level of ability the person has at a certain time. This might be influenced by physical and metal restrictions at a certain time which are reflected in the HealthData.
Other relevant data could be e.g., FinancialData to be able to make the salary payment, or pictures for access control. Also Suppliers and Customers might be relevant, e.g., for customer and supplier relationship management processes.
are needed to perform certain process steps. Possible resource types are device, item, fixture and application. Devices such as Robots could be further specified into IndustrialRobot, TransportRobot or other needed variants. Further relevant devices are Machines, such as the QualityCheckMachine (5) in Figure 1, or smart devices such as SmartWatches, SmartGlasses or SmartPhones. It is possible to define Functions (lines 44-48) for Devices and list relevant Abilities (line 47) and AbilityLevels (line 57) to be able to use or operate a certain resource. This is relevant for assisting employees.
The spatial context defines all elements relevant for navigation, mobility and virtual relationships. The definition of the relevant buildings, areas and other parts are strongly dependent on the concrete company and its structure. Starting from the Location, it is possible to define relevant FactoryBuildings, Areas on certain floors or Stations (lines 60-66) and relations among them (line 68). To relate certain Resources to a special Area or Station modelers can define Equipment on a certain position.
The behavioral context (not further described in Listing 1)
includes Behavioral Units, Operations, connections
between operations and Goals as well as Events and
Traces from event logs (see [
Clearly, the class diagram is not complete but it shows the most relevant classes and attributes for discussing privacy considerations of our use case. MDE approaches can be used to create the persistence layer and databases out of this model.
IV. PRIVACY-PRESERVING IOT SYSTEMS AND MDE The next steps towards privacy-preserving system design for IoT using an MDE approach are (1) to discuss privacypreserving systems design in the system architecture of our use case including relevant privacy checkpoints and (2) the privacy model which is needed to define the most relevant privacy data. We show (3) concrete examples for a purpose tree and the privacy policies and (4) the description on how to compare privacy policies and make the decision if data should be provided after a request or not.
In [
Company ABC
Resources
A
Operators
G Information
Portal PrC2 D
Primary Use
PrC4 F Secondary Use
Sensors
PrC1
B Data Collection PrC5 E
C Data Storage
PrC3
PrC5
Data Removal
Fig. 2: System architecture with privacy checkpoints
On each data pass, we have introduced and extended the
privacy checkpoints (PrC 1- PrC5) from [
PrC 1: Inform in (G) which data is collected, the duration of storage, possibilities for data removal and how raw data is combined (PP for data collection). Operators can give their consent and withdraw it. The portal ensures privacy control, the traceability of data needs to be ensured in the system architecture by considering all checkpoints. PrC 2: Inform in (G) which (real-time) analysis will be conducted and/or which services will receive the data for what purpose (PP for data use), about risks and benefits of analyzes and services, which services cannot be provided without access to the data and again options to delete the data at any point.
PrC 3: Inform in (G) for what purpose the data is used for (primary and secondary use), provide an option to determine how long data can be stored, provide possibilities to determine who has access to the data and obtain consent (PP for data storage and data use). A sustainable level of abstraction has to be considered before storing the data, unnecessary personal data has to be anonymized before storing (PP for data storage). (C) needs to provide means for data encryption and empower the data provider to be in control of that. If new purposes for data use occur (additions in the purpose tree) or other attributes of data are relevant for a purpose as well (changes in the purpose tree), (G) needs to inform the employee about these changes and provide possibilities to define new PPRs or change existing ones.
PrC 4: Inform in (G) which service has asked for access to the data and to whom access was granted (comparison of PPs), about aggregation with other data, if the data is exported or shared with a 3rd party. If new purposes occur, the employee has to be asked for consent again (define a new PPR). Moreover, the employee should have the ability to see the results of the secondary use.
PrC 5: (G) provides possibilities to delete the data at any point (during, at the end or after a service). Based on the retention time in the PPRs the deletion has to be done automatically after a certain period. After a deletion request, the data controller has to ensure that also analysis results and aggregated data are only kept if no connection to the data provider is possible.
These privacy checkpoints have to be considered in the system architecture.
The next step towards privacy-preservation is to define the
privacy model which includes the most relevant data to identify
important roles, define privacy preferences, define a companies
purposes for data processing and to handle data requests. As
discussed in [
Figure 3 shows the relevant privacy data as a class diagram and how it is related. Privacy-preserving systems need at least four roles: the DataProvider, the DataConsumer, the DataController and a DataAuthority. The DataProvider is the data source and should be enabled to verify the correct use of his data. Thus, it defines a PrivacyPolicy where it defines e.g., who can do what with his data. The DataConsumer is an entity with an interest in the data. It has to define a PrivacyPolicy which declares e.g., what it wants to do with which data for what purpose. Note that it has to be ensured, that only one relation between PrivacyPolicy and either DataProducer or DataConsumer can exist.
The DataController processes and stores the data and has to ensure the correct use of it. The DataAuthority is able to control the processing of data and can check compliance with data protection regulations. DataProvider
DataConsumer
DataController
DataAuthority String name 0..1 has 1 1 PrivacyPolicy String name PolicyType type 1 * has
String name
0..1 has
String name
String name enum PolicyType {Collect, Store, Use} enum ComparisonStatus {Requested, InComparison, Granted, NotGranted}
enum Country {Germany, Austria, US,+}
enum PurposeLevel {NoCollectionNoDistribution, CollectionNoDistribution,
CollectionLimitedDistribution, CollectionAndDistribution}
PrivacyPolicyRule String collector List<String> what String aggregation ZonedDateTime retentionTime PurposeLevel level List<String> recipients Country storage Country legislation ZonedDateTime validFrom <Optional> ZonedDateTime validTo * includes
* * * relatedWith
Purpose String name String description 0..1
*
DataRequest ZonedDateTime requestDate
ComparisonStatus status
Fig. 3: Privacy Model
Each PrivacyPolicy (either for collecting, storing or using data) consists of several PrivacyPolicyRules. They define very detailed (1) who collects the data (collector), (2) what attributes are collected and/or stored, (3) on which aggregation level the data is stored, e.g., each person, station, production line, and daily, weekly, monthly, (4) how long the data could be stored (retention time), (5) what purpose level is addressed (see enum PurposeLevel), (6) which recipients are allowed to have the data, (7) in which country the data is stored and (8) the legislation of the country in which the data processing is carried out. Additionally, it is important to store historical information to know which PPR was valid when.
Every PrivacyPolicyRule is related to one or more Purposes. They can have further hierarchies as each purpose can be related with another purpose. Constraints need to check that the purposes for a tree structure in order to be computable.
PrivacyPolicyRules can be related with several DataRequests. Here it is stored who has requested access to this data by using which PrivacyPolicyRule and if the access to it was granted or not.
This privacy model is domain independent, so please remark that the privacy model is used additionally to the domain model. This means that relations between privacy and domain model have to be added such as the definition which class of persons can be a data provider or consumer, e.g., via additional and/or external tagging of the domain model.
Additionally to the defined models (domain and privacy model) it is important to define a concrete instance of the purpose tree and instances of the PPs (see Figure 4). The purpose tree should be defined by the company which collects the data to make it possible to use the purposes in the instances of the PPs which are defined by operators in a further step.
Domain Model
Personal and Social Context e.g., Person, Operator, Supplier, Abilities, Health Data, Skeleton Model, Financial Data Environmental Context e.g., Resources with Types Device, Fixture, Item or Application, relative Positions between Resources,
Functions, Instructions
There are several different ways for data controllers using MDA approaches to define a purpose tree: it is possible to use object diagrams (OD), a tagging language or any DSL with a tree like structure. Figure 5 shows an excerpt of such a purpose tree by using a simple graphical representation. The attributes named at the leaf level of the tree are clearly related to the ones in the domain model. Thus, it is important to check the purpose tree instance and domain model for consistency and to tag used attributes with the purpose in the domain model.
In our concrete example productivity analysis and to provide assistance e.g., by using ergonomic analysis or stress detection are relevant purposes. Figure 5 shows the related attributes for each of them. Other relevant purposes are e.g., to make the work contract by the human resources department, salary payment for the financial department, health insurance payments, access control or quality assurance.
general purpose analysis productivity assistance ergonomic analysis stress detection Station.hourlyProducedUnits Operator.surname Operator.HealthData. Station.medianDowtime Operator.familyname heartrate Station.ProcessEvent.* Operator.SkeletonModel.* Operator.HealthData. QualityCheckMachine. Operator. gpsPosition bloodPressure ProcessEvent.* Operator.HealthData. timestamp
Fig. 5: Example purpose tree (excerpt)
In a next step the operators define their PP instances. Figure 6 shows some examples, whereas the left side shows the PP of type use including three rules of a data provider (Susan Porter) and the right side two PP instances of different data consumers. These PP definition processes of data providers and data consumers happen independent from each other. Susan has defined a rule for productivity and quality analysis, one for ergonomic analysis and one for her data for stress detection. Her employers health department has defined one for providing assistance based on the health data. The quality assurance department of a supplier has defined a PP as well for productivity and quality analysis purposes.
Privacy Policy
Susan Porter (Operator) Owner Rule 1 Collector What
Company ABC Station.hourlyProducedUnits Station.medianDowtime Station.processEvent.* QualityCheckMachine.
processEvent.* Aggregation station, week Retention unlimited Purpose productivity, quality analysis Level C&LD Recipient Company ABC, Suppliers Storage Europe Legislation Europe Rule 2 Collector What
Company ABC Operator.surname Operator.familyname Operator.skeletonModel.*
Operator.gpsPosition Aggregation person, day Retention 1 year Purpose ergonomic analysis Level C&ND Recipient Company ABC Storage Europe Legislation Europe Rule 3 Collector What
Company ABC Operator.healthData.heartrate Operator.healthData.bloodPressure
Operator.healthData.timestamp Aggregation person, month Retention 1 month Purpose stress detection Level C&ND Recipient Company ABC Storage Europe Legislation Europe Privacy Policy Company ABC
Health Department Owner Rule 1 Collector What
Company ABC Operator.surname Operator.familyname Operator.skeletonModel.* Operator.gpsPosition Operator.healthData. heartrate Operator.healthData. bloodPressure Operator.healthData.
timestamp Aggregation person, month Retention 1 month Purpose assistance Level C&ND Recipient Company ABC
Health Department Storage Europe Legislation Europe
Privacy Policy PlasticFactory AG
Quality Assurance Owner Rule 1 Collector What
Company ABC Station.hourlyProducedUnits Station.medianDowtime QualityCheckMachine.
processEvent.* Aggregation station, month Retention 1 year Purpose productivity, quality analysis Level C&LD Recipient PlasticFactory AG
Management, Production
Management Storage Germany
Legislation Germany
Fig. 6: Examples for privacy policy instances
The data controller has to compare the policies of data consumers and providers to allow data transmissions. In case of policy conflicts, the highest data protection restriction of one or more data providers always win. If no PPR is defined for a purpose, there is no access granted to the data. The system compares each policy element of potential rules of the provider and consumer and decides whether access is granted or not. Decisions are stored as a DataRequest object.
Figure 6 shows an example: When the health department asks for the data defined in the PPR, each attribute has to be compared. The attributes in what are defined in Rule 2 and 3 of the data provider, the purpose assistance is in the purpose tree above ergonomic analysis and stress detection, so Rules 2 and 3 are relevant. The aggregation level month is the same as in Rule 3 and more general as in Rule 2, retention time is the same as in Rule 3 and less than in Rule 2, the purpose levels are the same, as well as recipient, storage, and legislation. Thus, access would be granted.
The same occurs for the PlasticFactory AG and their data request for the data provider: The attributes they request are less than in Rule 1 and the according purposes in the purpose tree, the aggregation level is higher with a month compared to a week, retention time is unlimited in Rule 1 and thus irrelevant, storage and legislation are in Europe. As a result of the comparison, access is granted. These decisions are stored in the DataRequest class of the Privacy Model in Figure 3.
Code Generation. The described models can be used as
input for MontiGEM to generate the system code and the
information portal (see (G) in Figure 2) [
Related work. Improvements for human workers
regarding the interaction with production systems in processes are
already ongoing work such as the transformation of the shop
floor into a smart environment with multimodal interaction
facilities to bridge the gap between physical world and the
digital part of the production system [
Considering privacy, security and trust in the IoT domain,
a broad variety of approaches exist. Nevertheless, most of the
lacks to tackle the human factor including information for
and control by involved humans. Sicari et al. [
Work on model-based and model-driven approaches
considering privacy exist mainly in other domains, e.g., [
Weaknesses and Limitations of the approach. The
proposed approach is easily applicable for greenfield design,
we expect that for adding privacy consideration into existing
projects and architectures further considerations have to be
made. This paper does not discuss security issues such as data
encryption or decryption [
Advantages using the approach. The use of MDE approaches improves the maintainability of privacy-preserving systems: for changing domain models or PrCs in architectural models, continuous re-generation facilitates the creation and change process and improves consistency requirements. As such changes might have effects on the operators’ privacy policy instances, these can be automatically checked against the domain model and suggest changes or additions for users. Further investigations of the maintainability are ongoing work.
Regarding the design strategies [
Our approach is domain independent and can thus be applied onto other use cases and scenarios where data is collected, stored and processed as well. Domain information is only included in the domain CD and the mapping between the domain model and the privacy model.
This paper presents an approach to include privacy considerations in the MDE development process of IoT systems and shows its application to a use case from human-centered industrial environments. We use a set of DSLs and MDE tools and frameworks to create an information system considering privacy-preservation and provide users and data providers with the relevant information to make informed decisions about their data use. We show a possible DSL model structure including domain models, a privacy model and possible instantiations as well as relevant aspects which have to be considered for the system design such as privacy checkpoints.
To sum up, our approach is easily applicable on similar use cases and system designs. Privacy preservation is important for other IoT systems as well such as assistive systems in general, smart home environments, wearables and health applications. Further investigations in other domains will follow.