# Technical Interoperability for Machine Connectivity on the Shop Floor
## 4 Results  
Data from the grinding process is collected through four separate systems: The grinding machine onboard computer, a vibration measuring system, IO-Link sensors, and an embedded sensor. While it is possible, to some extent, to connect the sensors to the machine PLC (Programmable Logic Controller) and transfer all the data from the onboard computer, that solution was not opted for because it would require extensive change in the machine, a task requiring an expert with very limited time. Each system supports different communication standards and/or methods, which made the overall system more complicated. To simplify this, the actor-based IoT middleware Calvin was used for aligning the data transfer. Calvin is a distributed software system, which allows its function blocks to run on different hardware while communicating seamlessly with each other. The reference implementation of the Calvin platform, Calvin-base [23], runs on most Linux systems, which means that Calvin can run in hardware in the local cloud as well as in the data center. The different connected systems are summarized in Table 1. The grinding machine computer and the vibration system are connected through the OPC UA standard, which they support to various degrees. The external sensors support the IO-Link protocol, which allows data extraction directly over TCP/IP (Transport Control Protocol/Internet Protocol). However, to simplify the connection to the Calvin actor, another gateway was developed that translates the TCP stream and shares the data as a RESTful web service. This translation software was developed using the Play framework [45], and the raw data could be mapped using the IO-link data sheets. The embedded sensor is a temperature sensor  
Figure 3: Summary of the project’s connectivity infrastructure. directly connected to a Raspberry Pi computer. Since Calvin can run on Raspbian, the Linux distribution supported by the Raspberry Pi, a Calvin actor can communicate directly with the embedded sensor. To connect the systems to Calvin, support for each communication or device was needed. This was achieved by implementing a plugin which handles all communication with the device or service in the platform abstraction layer, called calvinsys. The Calvin application, visualized in Figure 4, is running in a Calvin system spanning three instances: One on a Raspberry Pi located near the machine, one in the local cloud in the factory, and one running in the Ericsson Research data center. Letting the platform handle all specifics of the external service gives the illusion of the service being part of the platform itself. The function blocks, or actors, are distributed on the three calvinsys instances and the communication between them is seamless, meaning that the physical separation of the calvinsys instances is invisible to the function blocks. When the data has been transferred to the cloud through the Calvin application, it is distributed to three different data consumers: The database, the analytics application, and the mobile operator support system. The operator support system already utilizes the publish/subscribe protocol MQTT