Dirk Slama: Could you talk us through your sample solution sketch for an IoT sensor network?

Stefan Schuster and Julian Bartholomeyczik: Sure. A solution sketch includes both the problem space (the task set for the project) and the solution space (the technical solution that resolves this task). There are two different approaches for creating a solution sketch: top-down and bottom-up.

Let’s take a brief look at the terminology and typical approaches. We speak of a top-down procedure if a specific task has been set – for example, in the form of a question: How can we identify wear and tear on machines at an early stage? A technical solution that accomplishes this task is created and components are designed and created accordingly.

In a bottom-up procedure, components for the technical solution already exist – in the form of existing platforms, sensors, or algorithms, for instance. These projects are often exploratory in nature. A typical opening question in this case would be: “What can we detect in a machine using these sensors/this data?”

To help speed up projects, BCDS has created a platform construction kit that includes a development kit for sensor networks. The kit contains a wide range of sensors for all sorts of different applications.

In reality, projects are created using a combination of these two procedures. Platforms, for instance, can be approached from both directions. A platform can be designed either from the top down as a superset of application projects, or from the bottom up as a collection of existing technical components. Application projects rarely define a solution entirely from the top down; instead, they use existing components, for example from a platform.

Let`s use a concrete example – say we want to enable early identification of wear and tear on a machine with rotating parts in order to plan maintenance periods efficiently.

First, the project must be defined as precisely and as independently of the implementation as possible. Committing too soon to one implementation possibility can narrow the solution space prematurely and should be avoided.

In addition to the functional requirements, system requirements that define the framework of the solution must also be adhered to. These include cost limits, the environment in which the system must work, and set interfaces to existing systems.

Dirk Slama: So, what would you describe as good requirements?

Stefan Schuster and Julian Bartholomeyczik: The core questions are as follows: What does the user want to learn from the system? What actions must the system perform and when, and/or under what conditions? What are the basic economic conditions, and what environment must the system work in?

In this example, the user wants the system to inform them in good time about wear and tear on a machine. The machine is operated in an industrial setting. We assume that a process control system already exists and can be contacted via TCP/IP. We establish the price that potential customers are willing to pay for monitoring a machine, which results in a target price of €30 for manufacturing a sensor node. The system should be connected without cables and should have a battery life of one year.

For the functional part, a theory is established, from which we can derive the data required for the system to fulfill the task. In this example, the theory states that wear and tear on a machine can be identified through increased vibrations in the machine bed. This kind of theory is usually defined by a domain expert (i.e. an engineer who is familiar with the machine).

Ideally, the theory should be validated first. In our example, this is done by taking measurements at two machines: one in proper working condition, and one in the condition that you need the system to identify (i.e. parts are worn). This type of validation process can be used both to check the theory (vibrations increase when parts are worn) and to select suitable sensors (by using them to run tests). It also enables a mounting position or a series of suitable mounting positions to be determined at this stage. From these positions, other variables can be determined, such as available space and resistance to liquids and temperatures.

When the theory is validated, it is converted to a digital model. In our example, the measurements taken provide information on the extent of the vibrations, the frequency, and the changes to these parameters depending on the degree of wear and tear. Ideally, measurements are taken at multiple machines to determine the variance between machines.

Sensors are selected on the basis of the digital model, the non-functional requirements, and the experience gained from the validation process. Existing data might also be utilized (for example, does the process control system already know the rotation speed of the engines?). Data collection points are therefore specified precisely. And in a final step, the system can now be represented in a “solution sketch.” Please note that our focus is on the sensor perspective here, and not on the backend, etc.

In this example, the sensor system designed is fitted close to the axle bearing points in the machine. It is powered by a battery and transfers data wirelessly. An important decision here relates to where the digital model should be implemented. The following are two possible scenarios: In the first scenario, the model is implemented in the sensor node. This means that a simple message is sent to the superordinate system when the machine reaches a certain level of wear and tear. In the second scenario, the digital model is implemented in the central control system, which means that the sensor data is transferred and wear and tear is calculated in the superordinate system.

This decision is driven by the following considerations in particular:

• Energy requirements of the sensor node: Sending data requires a lot of energy. Preprocessing on the sensor node reduces the data transfer requirements.
• Available processing power and available data: Data processing can require processing power that is not feasible on a sensor node within the specified economic limits. If additional data from other sources is required to ensure correct calculations, then calculation can only be performed where all necessary data is available.
• The protection of know-how and the division of supply: If the algorithm needs to be protected, and if it was created by the sensor manufacturer, then implementation in the node makes sense.

In our example, the algorithm is implemented on the sensor node, as all required data is available, processing power is low, and battery life is essential.

Dirk Slama: Thanks! Finally, let’s talk briefly about the main components of the solution sketch.

Stefan Schuster and Julian Bartholomeyczik: The main components are the actual sensor element, a microprocessor, and an element for radio communication. Following tests with a microphone and an acceleration sensor, and after determining the frequency range and amplitudes, an acceleration sensor is chosen. The microprocessor is selected from the manufacturer’s construction kit (platform strategy, cf. bottom-up procedure) and the dimensions are such that the algorithm can run and there is still some space for enhancements. The radio connectivity is selected on the basis of the range requirements and battery usage requirements. A Bluetooth LE (BLE) connection is selected. A gateway is implemented which receives the data via BLE and then converts to Wi-Fi to enable connection with the process control system.