The more data the better. This is what big data analysis often boils down to. However, lone wolves are no longer needed today. The more complex the problems are, the more sensible it is to join forces with partners. As a result, production-relevant data is sometimes included in a joint data collection. How can you work together in a project in a spirit of trust?

In the SIDAP project (scalable integration concept for data aggregation, analysis and processing of large amounts of data in the process industry), operators (Bayer, Covestro, Evonik), valve manufacturers(Samson), field device manufacturers(Krohne, Sick), IT companies(Gefasoft, IBM) and the Technical University of Munich are working closely together. The aim is to identify new correlations from large volumes of data, for example from measuring devices. These in turn should provide information about the condition of a valve, for example, and ultimately ensure greater system availability. One of the key questions here is how to bring together different data sources from development, operation and maintenance, but also from different manufacturers, in such a way that conclusions can be drawn for new maintenance concepts, for example.

It is clear that the more data relevant to fault diagnosis is available for the devices used from different manufacturers and different users, the more meaningful the data collection will be. However, the necessary trust between the partners can only be established if there is legal certainty as to who is entitled to which obligations and which rights in the partnership. For this reason, various types of contract were examined for their practicality and feasibility during the course of the project.

On the one hand, fundamental questions arose during the project, such as who has which rights to which data, what is the liability risk and who prevents the data from being passed on? On the other hand, specific questions also arose: For example, how to ensure that the underlying calculation model receives the necessary information about a specific valve, but does not release any process know-how.

The project partners ultimately initiated a usage agreement as part of a strategic partnership. This specifies How the data must be prepared or who may use it. For example, before further use, the raw data is automatically anonymized according to the specifications of the data owner - such as the plant operator - meta-information that is not required for the analysis is removed and data series are normalized. Furthermore, in addition to tamper-proof and encrypted transmission of the data, secure storage of the data at the place of use was guaranteed.

However, it was also interesting to note that during these discussions and the development of a joint solution, it became apparent that the same errors in thinking kept cropping up, especially if the users had not yet thought about the respective aspect. The following five common misconceptions were uncovered and explained:

1. Data is an asset and there is an owner
2. New data protection laws are needed
3. All eventualities must be considered at the outset
4. Legal aspects are too complex
5. Security is only possible through compartmentalization

Misconception 1: "Data is an asset and there is an owner"

Data is not an asset that needs to be protected, as it can be copied at will. Consequently, there is no owner. What does exist, however, is protection in the sense of copyright law, i.e. comparable to music or books. In other words, an agreement can be made on the use of data records. However, process data is not generated by plant operators personally and therefore not by human creation, but exclusively automatically in a technical manner. It is therefore not eligible for copyright protection. However, the method of data analysis could very well be worthy of protection. There is also an ancillary copyright for databases. For the use of the database - i.e. by manufacturers who are not involved in such a project - corresponding usage and license agreements would apply. The protection of data and trade secrets must also be considered independently of the aspects mentioned above.

Misconception 2: "New data protection laws are necessary"

No, the laws are currently sufficient. But what is needed for the mutual exchange of data are 'rules of the game' for the rights of use. In the SIDAP project, for example, it was agreed that everyone involved in the project was allowed to use the resulting data. It was therefore the responsibility of the respective company to provide or prepare such data in such a way that it could be easily viewed by others. Such rules can also explicitly exclude purposes that contradict the purpose specified in the contract.

Misconception 3: "All eventualities must be taken into account at the start"

Not necessarily. It is advisable to first set out the 'rules of the game' in a contract, such as not passing on the data outside of this partnership. Specifying exactly which data sets are to be used and how is more of a hindrance to practical implementation. It is often not clear at the start of a project what data will be created and how it will be processed. Amendments, i.e. additions to the actual contract, allow the partners to secure themselves later on in an uncomplicated manner.

Misconception 4: "Legal aspects are too complex"

It is safe to leave the drafting of contracts to lawyers, but everyone should have a certain level of expertise when it comes to data security. Just as virus scanners have become a matter of course on private PCs, there should also be a certain amount of digital education on how to handle data.

Misconception 5: "Security is only possible through isolation"

This may seem logical at first glance, but you are actually blocking interesting opportunities. Networking enables new business relationships and models. Ultimately, no progress is possible without the exchange of data, knowledge and expertise. It is always important to weigh up individual rights against the common interest. To name just one example: It is clear, for example, that access control and thus the collection of information on when which person is in Building A may be life-saving for safety reasons at chemical sites. It is helpful if the fire department knows how many people are in the building. However, this data can also be used to determine a movement profile, which can show whether someone has overstayed their break. This example clearly shows that it is not about the data itself, but about the rights of use. And for this it is important to define usage rules, as was successfully achieved in the SIDAP project.

Author:
Prof. Birgit Vogel-Heuser heads the Chair of Automation and Information Systems at the Technical University of Munich.