Harting MICA Complete IIoT Starter Kit - Review

Table of contents

RoadTest: Harting MICA Complete IIoT Starter Kit

Author: stevesmythe

Creation date:

Evaluation Type: Development Boards & Tools

Did you receive all parts the manufacturer stated would be included in the package?: True

What other parts do you consider comparable to this product?: There are IIoT devices based on the Raspberry Pi (such as Brainbox BB and NetPi) and the Siemens IoT2040 Intelligent Gateway, but these are not ruggedised to the same extent as the HARTING MICA. The nearest equivalent I could find would be the VibroBox system, although that seems to be limited to vibration analysis and does not offer the broad range of applications that the HARTING MICA does.

What were the biggest problems encountered?: No real problems were encountered.

Detailed Review:


[Edited 15 June 2019 to include reference to my blog post describing how you can convert a 5v LCD to 3.3v and tweak a MakeCode extension to support the 20 x 4 LCD shown in this review]


Thanks to element14 and HARTING for providing me with the HARTING MICA IIoT Starter Kit to review. It has been very enjoyable to test this excellent kit and I hope that my review will convey an accurate impression of it to potential purchasers and anyone else interested.



HARTING is probably best known as a producer of industrial connectivity solutions (cables and connectors). It is a German firm, with offices in several countries including the USA and UK. In 2016, they brought out the MICA range of industrial computing devices, one of which is the subject of this roadtest.


What is condition-monitoring?

If you run a factory or carry out any other industrial activity that relies on keeping its machinery running well, condition-monitoring is the process of using a range of appropriate sensors to monitor the physical well-being of the machinery and its environment. By monitoring their equipment, a business-owner can identify whether the machinery is operating within its design parameters (e.g. temperature or humidity), and also, to some extent, whether it is operating correctly (e.g. excessive vibration or noise could indicate bearing failure).


Traditionally, industrial condition monitoring solutions were based on programmable logic controllers (“PLC”s). These use custom programming to display sensor information, usually on or near the equipment. PLCs are normally custom-designed for each machine and use a type of programming that is used by specialist field service engineers (but hardly anybody else).


What is IIoT?

The advent of the Internet of Things (“IoT”) has offered the opportunity of being able to remotely monitor and control devices through an Internet connection. The initial development of IoT solutions was based on microcontroller-based devices such as the Raspberry Pi, but such devices were not designed for the sometimes harsh environment of the factory, nor for 100% reliability over extended periods of operation. This has led to the Industrial Internet of Things (“IIoT”), which uses the same software platforms as IoT, but more rugged hardware and fault-tolerant software approaches. In Germany and some other parts of Europe, IIoT is also known as “Industry 4.0”.


The potential advantages of IIoT over the traditional PLC approach are:

  • Portability (the unit can be easily attached to any machine in any location in minutes).
  • Agility (re-programming PLCs is a specialist onsite job –IIoT programming can be carried out quickly, easily and offsite by non-specialists).
  • Ability to monitor machines remotely at any time of the day.
  • Ease of triggering automated actions based on the condition-monitoring.
  • Cost (the more generic approach means that bespoke solutions are not required).
  • Being able to retro-fit condition-monitoring systems on older machinery. (e.g. 15 year-old machines that might perform a critical function within a typical production line, whose main operating software protocol is no longer supported).


Potential disadvantages:

  • Increased security risks (e.g. industrial espionage, sabotage (e.g. DDoS attacks), opportunistic hacking, blackmail).
  • Dependence on continuous network/Internet connectivity.


Who are the target customers for the kit?

The rationale for the HARTING IIoT starter kit is to provide a complete, ready-made solution for people wishing to investigate and install IIoT-based condition-monitoring with the minimum of difficulty. This would include people wishing to retro-fit a condition-monitoring system to “legacy” equipment. By providing all the devices, connectors and software needed, the amount of expertise required to get started with IIoT condition-monitoring is minimal.


My review is based on the premise that the target customer is a relatively non-technical newcomer to IIoT-based condition-monitoring. My review will evaluate the hardware and software provided as well as the documentation and support available. I will also look at the potential for developing the use of the kit beyond the ready-made solutions provided by HARTING.


What’s in the boxes?

{gallery} Unboxing




MICA (a term invented by HARTING) stands for Modular Industry Computing Architecture. The MICA unit comprises three circuit board modules, in a rugged aluminium case. One of these (the Base module) is common to all MICA variants but the other two depend on the user’s application requirements.


The MICA base unit can be supplied by HARTING in a variety of configurations, including RFID and Ethernet. The model supplied for this roadtest was the HARTING MICA USB and it provides two USB ports for connector sensors and other devices. The MICA base unit also has a GPIO socket and a PoE network socket.



  • 1 GHz single core ARM v7 rev 2 processor (TI Sitara)
  • 1GB RAM
  • 4Gb eMMC
  • Supports up to 32GB microSD card (not provided)
  • GPIO 8 x 12-24V Inputs / Outputs (configurable via software)
  • 12-24v supply or PoE
  • 10/100 Ethernet


The GPIO connection is a USB to SPI protocol convertor device (MCP2210) that communicates with the MICA base via SPI and uses an Infineon SPIDER SPI driver relay control device (TLE7239SL).


Operating system

MICA is an ARM-based edge computer with network connectivity running a Linux-based operating system and a virtualized application environment build around Linux containers (LXC). Each application runs sandboxed in its own container with all libraries and drivers.  Communication between containers requires a separate IP address, increasing data security.  HARTING provides a range of pre-built containers that are ready-to-use, or you can build your own using their "MICA Container Development Guide" available on the HARTING Sharefile site (n.b. you might have to register your details to view the site). The pre-built containers include Linux Debian (two versions), MQTT, Node-Red, node.js and Python 2.7. The Debian Jessie container is intended for development rather than deployment and it uses up over 300Mb versus the Debian Stretch container which is around 40Mb. You can enable/disable any of the containers with a mouse-click (the greyed-out ones in the screenshot below are disabled).




Standards and certifications

An important selling point of the MICA range is that it is certified for use in a wide range of environments and settings, including:

  • EMC (EN 301 489)
  • Low voltage (EN 60 950)
  • Human exposure (EN 50 364)
  • Railway (tested according to EN 50155 (Q2 2016)

Bosch CISS sensor

As part of the IIoT kit, HARTING have provided a Bosch CISS multi-function sensor, together with a pre-configured LXC container that interfaces with the sensor. CISS is a Bosch acronym that stands for “Connected Industrial Sensor Solution”. Bosch themselves also provide example Python code that reads the sensor data and writes it to a *.csv file. There are also Bosch iOS and Android apps that allow you to view sensor data on a smartphone or tablet.



The Bosch CISS device contains:

  • Bluetooth Low Energy (BLE) radio
  • 32-Bit microcontroller (ARM Cortex M3), 1MB Flash, 128 kB RAM
  • User data memory 2MB
  • Accelerometer - BMA280 (capacitive MEMS)
  • Gyroscope - BMG160
  • Magnetometer - BMC150
  • Temperature sensor, Humidity sensor, Air pressure sensor - BME280,
  • Light sensor - MAX44009
  • Microphone - AKU340


Operating conditions


  • Operating temperature range -20 ºC – 80 °C
  • Humidity range 10 – 90 %rH (non-condensing)
  • Pressure range 300 – 1100 hPa
  • IP rating IP54
  • Supply voltage 5 V DC


Measurement ranges & accuracies


  • Accelerometer ± 2, 4, 8, 16 g (14 bit resolution) ± 50 mg
  • Gyroscope ± 2000 °/s ± 1 °/s
  • Magnetometer ±1300 μT (X,Y-Axis); ±2500μT (Z-Axis) 0.06 x M ± 25μT
  • Temperature -20 ºC – 80 °C max. ±2 °C + 3% T °C
  • Humidity 20 – 90% (non-condensing) max. ±7% at +20 °C, max. ±10% at -20 °C
  • Pressure 300 - 1100 hPa ± 1.5 hPa
  • Light 0 - 2112800 Lux ± 15 %


Sampling rate (USB)


  • Inertial sensors ≤ 100 Hz (Accelerometer, Gyroscope, Magnetometer)
  • Environmental sensors ≤ 1 Hz (Temperature sensor, Humidity sensor, Air pressure sensor, Light sensor, Microphone)
  • In “inertial sensor special mode”, the accelerometer can report at 2000Hz (but all the other sensors are disabled in this mode)


Mounting the CISS

The CISS has two mounting holes which can be attached to the device under test by bolts/nuts, or by the included magnetic mounts. Nb. To obtain accurate magnetometer readings, the magnetic mountings must be removed and the sensor should be mounted using bolts/nuts.


The light meter is on the back of the Bosch sensor, which means that light level readings are likely to be lower than expected. If required, the sensor could be mounted with the light level meter on top, but mounted that way round, the protective membrane for the sensors could be damaged more easily.




Cables and connectors

The cables provided with the kit are:

  • A M12 X-coded PoE network cable with a HARTING push-pull RJ45 connector on the other end.
  • A 1m-long 12-core GPIO cable using M12 A-coded connector on one end and 2.1mm centre-positive socket at the other (for connecting to a power supply).
  • A HARTING USB Push-Pull CISS cable for the Bosch CISS sensor. This is a USB connector fitted with a plastic shroud that provides IP67 compliance and a “click shut” latch to hold it firmly in place.


A HARTING Push-Pull USB port protection cover was also supplied to maintain IP67 compliance for the spare USB port. However, there was no protection cover provided in the kit for the GPIO socket (for example if the MICA is powered via PoE), but I was able to buy onebuy one for around £3.00.


Power supply

Supply voltage for the MICA base unit is specified as between 12v and 24v.


The MICA is obviously intended to be powered via the PoE-enabled network connector. However, you could alternatively use the supplied GPIO->2.1mm centre-positive connector and the 12v 1A switching power supply. Although it is convenient to be able to power the device even if you don’t have PoE, the provided cable has been sealed (presumably to maintain its IP67 rating) and prevents access to the GPIO ports. If you need to access the GPIO ports, you will need to make your own connector.


The supplied power supply (with US plug) did power up the MICA base unit, but it didn’t seem to have enough power to fire up the Bosch sensor as well, so I re-purposed a 12v 1.5A power supply from an old router and this worked reliably. At the other end of the voltage range, I also successfully used a 24v 5A power supply.


Another point worth mentioning is that if you do power the device via PoE, the GPIO pins are unpowered.


The MICA has clearly been designed with security in mind, although this is not always evident from some of the demo containers and documentation provided.


As all MICA applications run in individual LXC containers, which run in separate kernel namespaces, this limits the damage that could be done if a hacker gains remote access to one container. This would make it very difficult for a hacker to reconfigure the MICA hardware, the kernel or gain access to the MICA Base file system.


Communication to containers over the most common ports like 80, 8080 (HTTP), 443 (SSL) get rerouted through the MICA Base, so there is no way to access container web servers and the container GUI over un-encrypted connections.


Nonetheless, the potential for industrial espionage still exists if hackers can gain access to the secure web pages that provide a stream of environmental monitoring information, so precautions (such as choosing secure passwords and ensuring that the MICA base has the latest security patches) should be taken to minimise the likelihood of unauthorised access to those pages. Similarly, DDoS attacks on the MICA webservers are still possible, so intrusion detection software would be recommended.


The current MQTT container provided by HARTING is not secure and data could easily be intercepted if exposed to the Internet. During the course of the review, HARTING provided a link to a secure MQTTs container, but I have not yet been able to test it.



Much of the information for the MICA on the HARTING website was written in 2016. This does not necessarily imply that it is out of date (although some of it is), but it can be confusing when the documentation does not match the system. There did not seem to be any documentation about how to use the GPIO container with MQTT and Node-Red.


I did find the HARTING website consistently slow which made searching for parts (such as cables and connectors) difficult unless you know the exact part number. The titles/pictures of the various connectors and cables that they offer are very similar and run to many pages.


First impressions

First impressions of the IIoT kit were that the MICA is a beautifully-engineered piece of kit that exudes quality. HARTING have provided all you need to get started with IIoT so you don’t need to know the difference between M12 A-coded connectors and M12 X-coded connectors, or hunt around for an appropriate set of sensors and cables to connect it all together. It’s all there and ready to use. I was pleased that the cables provided were nice and long, which makes it easy to integrate in an existing setup.


Installation and configuration

I followed the instructions in the HARTING MICA CISS Complete IIoT Starter Kit Setup Guide to configure the MICA base, Bosch CISS sensor, MQTT and Node-Red. The instructions take you through the process of connecting the MICA directly to a PC step-by-step and are quite clear. I suppose this is to ensure that the equipment itself is up and running as quickly as possible, without any added complications arising from network configuration. This involves connecting to the MICA base, then configuring the pre-installed CISSGateway container to send the sensor data to the pre-installed MQTT container. The MQTT Broker Container is based on the open source MQTT broker project Mosquitto v1.4. The pre-installed NodeRed container then needs to be configured to collect the sensor data via HTTP from the MQTT container.


At the end of the process (which took around 10 minutes as HARTING had promised), I had a working system that I could test and familiarise myself with.




As far as I could tell, there is no guide that tells you how to integrate the MICA into an existing network, although it is quite straightforward and pretty much a case of enabling DHCP on each of the containers that you want to run.


The firmware and pre-installed containers are not the latest versions, so the next step was to replace them with the latest versions. The MICA provides a very easy way to do this – you just find the container that you want to install from the HARTING MICA Container website and download it to your PC (usually as a *.tar file). Then, you use the pre-installed “Install” container to load, decompress and install the new container – and it all happens automatically. All that remains for you to do then is to configure the network settings to match your own network preferences and reboot the MICA. Rebooting might not be necessary but I got into the habit of doing it after I found that the CISSGateway container wasn’t connecting properly to the sensor without a reboot.


Having updated all of the pre-installed containers to current versions and configuring their network settings, I then had an up-to-date working setup which allowed me to view the Bosch sensor readings in realtime via a NodeRed dashboard. To minimise any potential security issues, I did not expose any of the MICA containers to the Internet, so everything was kept on my own network. The dashboard is in Node-Red and you can pretty it up quite easily by adding data-responsive colours to dials, degree symbols etc..




After I had installed the Bosch sensor on the MICA, I also downloaded the Bosch “Virtual CISS” app onto my iPad from the Apple App Store and onto my Android phone from the Google Play Store.This allows you to stream (and graph) data from the sensor to your iOS device (the Android version seems identical in use). The chart below shows accelerometer data resulting from me swinging the CISS sensor round and round in the air!



The app has a button “Logging”, which will allow you to log sensor data to a file, but that function was not yet enabled at the time of testing (either on the iOS app or the Android app). Nevertheless, the app is very useful to be able to get an instant graph showing realtime sensor readings. When deciding where best to place the sensor to pick up vibrations from a machine, this app gives you immediate information to inform your decision rather than having to wait to view the MICA’s logs.


I tried this app with the sensor just powered by a USB power plug (i.e. not directly connected to any device) and it worked fine.


Test 1: Sensor accuracy

I tested the Bosch CISS sensors against a range of “known good”, accurate sensors that I already own, including the Kitronik Klimate sensor (see my RoadTest), which uses the same environmental sensor as the Bosch CISS (BME280). The specification for the accuracy of the BOSCH sensors is quite modest and it should be no surprise that the sensors that I tested fell well within that specification. First, I tested the three BME280 sensors (temperature, atmospheric pressure and relative humidity) against the Klimate/BME/micro:bit combination. In this test, I placed the Klimate board and micro:bit next to the CISS sensor and sent its data by radio to the micro:bit in the Grove shield attached to an I²C LCD display. In case you are wondering, this blog post shows you how to convert a 5v LCD to 3.3v for use with a micro:bit, and how to tweak the MakeCode extension to support the extra two rows and four columns.




Next, I tested two of the inertial sensors in the CISS (accelerometer and magnetometer). For this, I used the Bosch Python Demo Script (see Test 3 below) running on the MICA, accessed on my PC via PuTTY and tested against the micro:bit's own accelerometer and magnetometer. I was careful to align the sensors on both devices along the same axes. First the accelerometer:




Next, the magnetometer:




The readings were reasonably simiIar between the two devices.


I was not able to test the gyroscopic sensor, the light level sensor (I had no comparable sensor available) or the sound level sensor (no specification provided). The only other gyroscopic sensor I have is a Lego Mindstorms Gyroscopic sensor. I could not work out how to safely test both sensors so that they were synchronised and in the same inertial frame of reference. As I was going to be doing some testing of the MICA in my car (see Test 4 below), I did think about driving around with the MICA and the Lego Mindstorms sensor at the same time. However, not having access to private roads, I realised that it would not be easy to contrive a suitable test circuit without creating safety issues for myself and other road users!


All the tests that I carried out showed that the CISS sensor operates within its specified accuracy.


Test 2: Automation using MQTT and NodeRed

My next test was to install the HARTING GPIO container so that I could try out some automation using NodeRed. As previously mentioned, the GPIO cable provided only has a 2.1mm power socket on the other end – preventing access to the other GPIO pins. Not wanting to mess this cable up, I bought a spare GPIO cable and made my own breakout board. The HARTING documentation for the GPIO connector (contained in the HARTING HAIIC MICA Hardware Development Guide) was a little difficult to follow because the pinouts for the socket wiring were on a different diagram from the GPIO channel assignment. Channels can be configured as inputs or outputs and the GPIO voltage matches the input voltage (shown below as +24V, but can be 12V or anywhere in between).





Also, the pin number addressing in the GPIO container is not the same as MQTT. For example, “pin7” in the GPIO app needs to be addressed as “pin6” in MQTT. I combined them into the table below:






This made it easy then to wire up my breakout connector so that each GPIO pin is lined up in numerical order.





Now that I had a usable cable, I was able to connect a switch and a relay to two of the GPIO pins and manipulate them using the HARTING GPIO container interface screen.


Once this was working, I used MQTT and NodeRed to implement some simple automation.


The first example is to replicate the situation in a factory where a rise in machine temperature triggers a relay-controlled fan to cool the machine down again.


I attached the Bosch CISS sensor to my “machine” (which was actually the Linix motor provided for the New Year’s Grab Bag RoadTest). I created a flow in Node-Red that sets GPIO pin1 high (and actuates a relay connected to that pin via my breakout connector) when the temperature reading on the Bosch CISS sensor exceeds a specified value, and turns it off again when the temperature reading drops below a specified value (in reality, I would allow for hysteresis between the on/off temperatures to prevent oscillation, but that would have made the video too long!).


{gallery} Node-Red



I connected a toy POV  fan motor to the relay to cool the motor.




Surprisingly the draft from the toy fan was actually enough to cool the motor down, whereupon it turned off.



Because the MICA is Internet-connected, the factory owner could monitor this process remotely. This might seem a trivial example because a thermostatically-triggered fan does not need a fancy IIoT device like the MICA/Bosch combination to do its job. However, what this example demonstrates is that the MICA’s hardware is capable of interfacing with other devices, and that those devices can be part of the overall Internet condition monitoring solution.


The second automation example is where an open door in the factory triggers an alert over the network (or Internet) that switches on a red warning light on another device (I used a Raspberry Pi) in a different place.


{gallery} RPi Node-Red





Once again, separate alarm systems could be used for this, but it is just an example of how the MICA supports simple-to-deploy automation that is not limited to the hardware included in the IIoT kit.


Test 3: Condition monitoring with the MICA

At its simplest, you can use the Bosch sensor to be able to tell, remotely, whether your machine is running or not. This could be from the accelerometer readings, or temperature, or other indicators. Working up from that, you can see what your machine is doing (see the washing machine example below) and even assess how well your machine is running.


To carry out condition monitoring, you will need a way of collecting and analysing data from the Bosch sensor. Since the Bosch BLE app does not currently provide a way of storing the data, the easiest route is to run the Bosch-provided Python program, either on a PC, or (in this case) on the HARTING MICA.


I tested the Bosch Python program first on my PC (using the Bosch “Demo Script Python – Operating Instructions” that I downloaded from the BOSCH website) and this seemed to run properly so I then tested it on the MICA. The "HARTING MICA CISS Complete IIoT Starter Kit Setup Guide" doesn’t tell you how to do this, but I installed the HARTING “Debian” (Jessie) container and installed Python on that. In brief, these are the steps I followed:

  1. Install Debian Jessie container using the “Install” container.
  2. Connect to the Debian container with PuTTY and change the password for root.
  3. Run “apt-get update”, then “apt upgrade” to bring the Debian up-to-date.
  4. Run “apt-install python27” to install Python 2.7.
  5. Run “apt install python-pip” (as Pip was not already installed)
  6. Use Pip to add a couple of Python packages (pyserial, configparser) that are needed for the Bosch Python Demo Script but were not already installed.
  7. Use WinSCP to copy the Python Demo Script files from my PC to the MICA.
  8. Change a line in the Bosch file “config.ini” to use the correct port on the MICA that the CISS sensor is using to “port = /dev/ttyACM0”
  9. Run the Python script.


This results in a file "dataStream.csv" being created in the same directory as the Python script. By default, each line of the file provides the readings from each of the sensors at the chosen interval (set in “settings.ini”). You can choose which sensors, streaming mode and sample rate. Streaming mode is useful as you can just stream everything, or only stream data when the data falls outside a parameter you can set (e.g. a temperature above/below a threshold).


I had planned to monitor sound and vibrations but it appears that, although there is a microphone sensor, sound data is only available via Bluetooth (i.e. not via the USB connector on the MICA base unit).


Each line of the csv file has a Unix epoch timestamp (calculated as the number of milliseconds elapsed since 01 January 1970). If you want to convert the timestamp to date and time format you could do it with Excel - the Excel formula needed is “=((((A1/1000)/60)/60)/24)+DATE(1970,1,1)”.


You can modify “settings.ini” according to the sensors that you want to use, and how often to collect their data. I wanted to measure the “vibration profile” of my Bosch image  washing machine as a way of demonstrating one type of condition monitoring, so I clamped the Bosch CISS to the front of my washing machine. Since I don't have access to a factory, I thought that my washing machine, which is noisy and vibrates a lot during the spin cycle, would make a good test machine. For vibration analysis, you need to enable the accelerometer’s “special mode” to collect accelerometer data at 2000Hz.






Each time you run the Python program, data is appended to the csv file. I downloaded the file to my PC for analysis using WinSCP.




This file can get very big very quickly (especially at 2000Hz) so Bosch have provided another example Python program that creates a new folder "/data" and starts a new csv file every x minutes (configurable), which might be more manageable.




My washing machine’s quick cycle takes around 15 minutes, but results in around 2 million data points, so using Excel for graphing and analysis would be a frustrating experience.


I used MATLAB to plot the data collected from the Bosch CISS.  Once your data is in MATLAB, there are plenty of analysis tools available to you.


I ran the “quick washing cycle” twice, on two different days. If you look at the two graphs, you will see that the “vibration profile” is pretty consistent, although the second run took longer and shows an extra "spike" just after row 300,000, due to a heavier load inside the washing machine.




From the vibration profile, you can identify the different parts of the washing cycle. This is where “machine learning” comes in. You can “teach” a machine learning system what a “normal” vibration profile looks like and you can also teach the system what the vibration profile would look like under different types of malfunction.


This could be done in MATLAB or by sending sensor data to Microsoft’s Azure Cloud for further storage and analysis using Microsoft Azure Machine Learning Studio (see Test 5 below).


My washing machine is running well at the moment but, from experience, if the motor’s motor brushes or main bearings wear out, you would see a very different profile. MATLAB offers tools such as a Fast Fourier Transform function, to carry out further analysis of the different frequency spectra produced by good vs faulty motors which can help predict if the motor under test is likely to fail shortly. I should point out that this is not a trivial exercise and requires a good understanding of physics and maths.


Test 4: Road test!

Some insurance companies nowadays offer lower premiums if you agree to having a “black box” fitted to your car. These send telemetry data to the insurance company, which can then see how you are driving. I thought it would be fun to carry out an actual “road test” of the MICA to look at the accelerometer data from two different car journeys. This was also a test of how the MICA fares in a fairly rough operating environment. I was able to power the MICA from one of the 12v power sockets fitted in my Ford Focus.


As an initial test, I took some accelerometer readings from the engine bay with the engine ticking over at 900 rpm and then revved up to 4000 rpm (twice).






For the actual on-road testing, I didn’t want to cause any safety issues, so I made sure that everything was inside the passenger compartment. The most difficult challenge was finding some ferrous metal inside the car to mount the Bosch CISS onto, given the preponderance of plastic and cloth in a cheap Ford interior! I found a reasonable mounting spot on one of the brackets that holds the rear passenger seats in place.




The first journey was a 38 minute stop-start journey across South East London and the second was a 40 minute journey on a mix of roads, including some dual-carriageway (a.k.a. freeway) cruising.





The data from the 40 minute journey resulted in a csv file with over 1.6 million rows (which comfortably exceeds the latest version of Excel’s 1,048,576 rows limit image ) and nearly 5 million data points, but MATLAB handled it easily. I was impressed that there were no obvious errors or outliers in the data collected, even though the boot (trunk) of a car is a bit of a hostile environment for any kind of computer.




Test 5: Sending sensor data to the Microsoft Azure Cloud

I mentioned above that, as an alternative to MATLAB, you could use Microsoft Machine Learning to help with analysing your data. To do this, you will first need to send your sensor data to the Microsoft Azure Cloud. Assuming you already have an active Azure account (free ones work fine), it is simply a matter of allowing the MICA MQTT container access to the Internet, adding an IoT Hub in Azure and configuring the Azure IoT Hub node in Node-Red with the primary key connection string that Azure automatically creates for you. I worked through these steps and was able to see the telemetry messages on my Azure account moments later.


Having configured the IoT Hub in Azure, you then need to set up a storage account in Azure (I used Blob storage) and a Stream Analytics job to send the data from the IoT Hub to the Blob storage. Now, all the data being sent from the MICA, via Node-Red, to the IoT hub in Azure is being stored in the Azure cloud. The gallery below shows the steps that I used:


{gallery} Azure










To prove that the data streaming and storage process was working, here is a screenshot of what (some of) the data looks like in Azure Blob storage after I had downloaded it back down to my PC and opened it in Notepad++.




The next step is to set up a Microsoft Machine Learning Studio account to analyse your data.




If you are new to this, there is a worked example of using Machine Learning for predictive maintenance in the Microsoft Azure AI Gallery.


I won’t go into this further as, although the principles are straightforward, it involves a lot of steps and I don’t have enough data (i.e. data from a malfunctioning washing machine) to do anything meaningful.


Beware that, even with a free Azure account, after the first 30 days of opening your Azure account, Blob storage, Stream Analytics and Machine Learning studio will incur small charges, depending on the amount of data being transferred and stored.


Note that this was using the insecure HARTING MQTT container so my data could easily have been intercepted. After leaving it running for a while, I turned off Internet access for the MQTT container and deleted that data from Azure.


Overall assessment of kit

This kit is a great way to investigate Industrial IoT and condition monitoring. HARTING give you all you need to get started (hardware, software and documentation) and it all works well together brilliantly. The long cables and study connectors provided made it easy to place the MICA and the CISS sensor where I needed to. The only thing missing from the kit is a cover for the GPIO socket when not in use (e.g. when the MICA is powered through PoE).


The MICA itself is an attractive, well-engineered and robust unit. By having PoE capability, it is easy to locate the device in hard-to-reach places, as all you need is to run a PoE network cable out to the device. The spring weather in the UK did not allow the device to be tested in extreme temperatures, but with the MICA rattling around in the boot of my car or attached to my noisy washing machine, it never missed a beat. Although I considered pouring water over them to test the the IP67 rating for the MICA and the IP54 rating for the Bosch CISS sensors, their design and construction gave me no doubt that they would have withstood that test, so I did not.


Providing access to industrial-style GPIO connections increases the scope of the device and makes it easier to integrate with other systems and sensors.


The Bosch CISS sensors are accurate enough, and they are rugged and reliable and well-suited to condition monitoring. The Bosch app makes it easy to test out various sensor locations without having to download the data from the MICA. I am looking forward to the next release of the app, which will provide a data-logging facility.


The MICA has clearly been designed with security in mind, although this is not always evident from some of the demo containers and documentation provided. I hope that the new MQTTs container turns out to provide proper security for streaming data to the cloud as maintaining data security is the biggest issue in IIoT, in my opinion.


Although there is a software "reboot" button, there seems to be no way of executing a controlled shutdown. Knowing how data can become corrupted when power supplies are interrupted, I always feel uncomfortable just pulling out the power plug. Maybe HARTING have designed a way for the MICA to save any open files when it detects that the device loses power but I could find no instructions or documentation about it.


The kit costs around £1,500 plus taxes. Compared with (less rugged) Raspberry Pi-based solutions, this might look high. However, in the context of looking after machines costing tens or even hundreds of thousands of pounds, and the costs of lost production, I think it would be an investment well worth considering.


[Edited 15 June 2019 to include reference to my blog post ]