IoT in LHC: Introduction

Published:08/17/2017   Last Updated:08/17/2017

I’m Lamija Tupo, a student from Sarajevo, and I’m a CERN summer student as part of CERN Openlab. I’m working on ‘Edge Computing: Integrating IoT Devices into the LHC Control Systems’ project using the Intel® Joule development board.

At the beginning of every project, there’s the question of which technologies to use. Sometimes, they are defined, yet sometimes we get to choose ourselves. I’ve had that opportunity on my part of the project. Although some of the technologies were decided upon beforehand, I got to choose the framework. Nowadays, it seems like there’s a new framework every other day. It would take weeks, months even, to go through them all, compare the features, and find the optimal one. Even in that case, there would probably still be a couple which fit the requirements. Of course, depending on the project, it might happen that no frameworks fit all the requirements. Therefore, the first step is understanding the most important requirements of the project.

We started the project with a minimal set of requirements in order to enable the communication between sensors and analytical applications through an IoT architecture. The sensors are connected to one or more Intel Joule development boards. The boards should announce the presence of the sensors to a discovery service based on mDNS. Then, the data is published via Kafka. On the other side, the analytics master or another system can query the list of available sensors from the discovery service. After retrieving the sensors list the analytics master can subscribe to the specific Kafka topics in order to fetch the data (published by each IoT board). Below is the diagram of the architecture of the components for this part of the project.

Project Architecture

The second step was comparing the available open source frameworks that could fit the initial given requirements. That list consisted of AllJoyn, SiteWhere, OpenSensors, IoTivity. All four frameworks had a lot of positive points, but we decided to use AllJoyn because it provides a more dynamic configuration and an implementation of the mDNS protocol. Therefore, the chosen technologies are: mDNS, Kafka, and AllJoyn. The reason why we need to use mDNS is because there will be many IoT boards and devices connected in the network, and they need to be able to communicate. Kafka is used instead of standard pub-sub protocol because it stores data in a distributed queue, which makes it both efficient and capable of managing a large amount of data. AllJoyn is mainly used for its mDNS implementation and dynamic network configuration.

In the sea of frameworks, protocols, algorithms, libraries, etc., there’s often a detail in each project which makes one of those technologies better suited for it. Finding it may be tricky, but it can set course of the whole project. 

Product and Performance Information


Performance varies by use, configuration and other factors. Learn more at