Privacy Compliance in Industrial Automation Scenarios

Part 1: How the automation industry is affected by GDPR and what should be cared about in the design process

What brought us here?

Usually we focus on the development of robots and strive to enhance them with exciting technologies like borderless navigation or person and object detection. Nevertheless we also have to take responsibility for the data we are processing, especially if we are interacting with people. Privacy is not a regular nor popular subject in automation especially in the factory domain. We face that matter as well as the high-level requirements and love to give you a brief insight on concepts regarding privacy and security.


Why privacy matters in automation

More and more objects in our daily routine become automated and interactive. Cars help us getting into parking space or even drive autonomously. Our homes are becoming smart with little boxes that talk to us or a fridge that’s keeping inventory of our groceries. Little humanoid robots like Pepper or Sanbot are populating lobbies, fairs and other marketing events. In supermarket we get used to checkout on a machines. There are also AGVs — autonomous guided vehicles, rather known from warehouses and production— swarming through Walmarts now, helping the employees with restocking of inventory.

Collaborative work scenario with person and object detection

However, the productive sphere for human-robot-interaction is still quite small. AGVs and industrial manipulators usually slow down for any unrelated object that comes into its working space. Many setups even forbid any human in their environment realised with cages and optical barriers.

This is slowing down the effective production and reduces the possibilities of customised applications for worker-robot interactions. With new technology it’s possible to add fast cameras and human recognition to the setup where robots only slow down for humans, not arbitrary objects and only in critical area.

Caged environment for industrial robots

As a side effect you bring legal obligations into setup:

  • The control loop must be reliable for safety requirements.
  • It violates privacy and employee laws if it is not handled properly especially in combination with other data.

The latter had an impacting change within the European Union lately. The General Data Protection Regulation (GDPR) went into effect on 5/25/18. It aims to protect the privacy of all EU citizens and to avoid data breaches in an increasingly data-driven world. While its biggest consequences might hit the web industry, it also affects almost every other organisation as well. In the following section we introduce the most significant impacts towards the automation's domain.


GDPR at a glance

The background of the GDPR is a long and time consuming process of negotiations between the European commission, the parliament and council, not to forget uncountable lobby groups from civil rights to online marketing. It started in early 2011 to be finally adopted in Mai 2016 and went into effect on May 25th 2018. The visible effects are now annoying consent emails and popups on almost every website. The non-visible effects could bother a lot more if you are the controller for the processing of personal data in terms of GDPR. What kind of data is considered personal? Article 4 states that any information relating to a person is personal as long as it is connected to information that can (in-)directly identify that person. That could easily include sensor data close to workers, especially if audio or image data is processed. The effort you have to spend in order to act in compliance with GDPR, highly depends on which, how and how much data you are processing. Therefore you must take care of privacy already at design level.

In very short you have two options:

  1. Anonymise the data, which is not easy at first, but the better choice if possible.
  2. Reduce the data to what is essential, pseudonymise where possible and get a free and informed consent for every non-essential process.

Anonymisation means, that you have to cut everything from your data that links it to a particular person. Afterwards you must not be able to identify any person anymore. Pseudonymisation is similar, but a link is remained at a different place. That might be a number or an ID of which you hold a map to real names in a database that has stricter access. The essential of the data depends on the legal basis (Art. 5–6) and the exact purpose of the processing. Example: In order to control an automated door for arbitrary persons with a video camera, it is necessary to detect but not identify the persons. You would need their consent for the latter. If you plan to use it for bio-metrical authentication, that would be legal but does not give you the implicit possibility to track the mood of your employees.

Some further aspects should also be respected in design:

  1. Is the data of a special category? That means for example data concerning health, from children or with political opinions of a person? Therefore the purpose must match one of the given exceptions from Article 9 (2) or get an explicit consent. It then must be taken care of further constraints and obligations (in following articles).
  2. Who is the controller of the processing? Her/he will be responsible for the processing and must be well informed about it. The controller will also be stated on any document handed to authorities and data subjects.
  3. Will your processing require a Data Protection Impact Assessment (Article 35)? If it cannot be avoided, this puts a lot more research, testing and documentation into your process.
Flowchart for actions regarding GDPR compliance. © 2018, GESTALT Robotics

So far, what did we learn out of this? The GDPR is not forbidding the use of modern technology at your production site and robots with modern technology. It just forces you to define its purpose and use your technology only that if humans are part of your process. This prevents data of being misused and guarantees that companies treat the privacy respectfully.

In part 2 we will get more into detail with a factory scenario and two particular collaborative use-cases. It might help you to analyse your own process and find the legal requirements for it.


Disclaimer and Acknowledgement

The presented statements and analysis towards the GDPR was made on basis of the legal text and further literature research as well as simplifying assumptions. Some precise interpretation will only be found in court unfortunately. In addition, it should be noted that the authors
do not have any legal education and therefore this is not a legal advice and there are no claims to made. For a productive implementation of similar scenarios, we recommend to consult legal advice.

This article is based on the scientific paper from Tom Kittmann, Jens Lambrecht and Christian Horn: A privacy-aware distributed software architecture for automation services in compliance with GDPR. It was published in the context of the IEEE ETFA 2018 (International Conference on Emerging Technologies and Factory Automation).