RoadTest: Harting MICA Complete IIoT Starter Kit
Author: Jan Cumps
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?: For ease of development, management and deployment: BeagleBone, Raspberri Pi, Siemens IOT2000 For use in an industrial environment and certification: Siemens IOT2000
What were the biggest problems encountered?: None
Detailed Review:
I road tested the Harting MICA Complete IIoT Starter Kit. This report documents my experience. It's an overall positive experience - a high quality device made for industrial service.
|
The Harting MICA is a small box Linux device, made for industrial applications.
It's a little rugged box with a decent ARM microprocessor and decent specifications.
The MICA design focuses on running in rough settings - not on high end performance specs of the processor and peripherals.
The mechanical reliability, shock resilience, protection from liquids, quality connectors and DIN mounting option are all part of that.
The device runs Linux as base operating system. Management is via a web interface.
Custom applications and ready-to-use function modules are added via software containers - isolated virtual machines that run on the base Linux.
image source: application note White Paper MICA Security
Harting published a set of containers. Some examples are:
image source: application note White Paper MICA Security
There's an ecosystem of partners that provide specific containers for industry applications and integration: MICA.network.
Some of the solution areas:
Next to the ready-to-use ones, some of Harting's containers are intended to be a starting point for your own development.
I've used those extensively. Check the links at the end of the review for the customisations and programming I did on the MICA.
Security is implemented on several levels.
The base Linux isn't accessible to anyone. You install it as a signed firmware update and never talk to it, except via the web interface and a set of APIs.
When deploying your solution containers on that base OS, you can decide yourself how closed or open you configure the access.
There are options to restrict the external devices available to containers.
I've posted some articles on how to make containers with different security access than the Harting ones - also listed in the links at the end.
The processor is a 1 GHz ARM, available memory 1 GB RAM and 4 GB eMMC. You can add external storage via a microSD - up to 32 GB.
The IO options are very different than what you usually find on the Linux single board products.
There are other MICA configurations that have other I/O configurations. Harting also has a base box with GPIA and Ethernet.
You can customise that box with your own hardware. There's documentation available on the size of the PCB that can be hosted, where the mounting points have to be, connection layout and installation instructions.
image source (edited): Flyer Harting Mica
The front panel is made of fiberglass reinforced plastic and can be customised.
Power can be provided in two ways: power over internet (PoE) or via the I/O connector - 12 to 24 V.
The I/O voltage level is the same as the one you provide via the I/O port.
This is a great industrial devise - whether you want to deploy it as an edge device or a control unit in your control rack.
My review (TL;DR: positive) has remarks on some aspects, but that's natural in a Road Test.
Overall, I'm seriously impressed by the Harting MICA as a rigid and capable device in industrial settings.
You can see that the hardware is made by a company that's an expert in sturdy manufacturing.
The build is strong. All measures are taken to harden the MICA for use in harsh environments.
Several industry certifications (including railroad industry ones) show that this device can withstand abuse - environmental and mechanical.
image source: HARTING MICA® CISS Complete IIoT Starter Kit - Data Sheet
It's a strong housing, made of aluminium. The front panel is made of (attention: flyer lingo 
) fiberglass reinforced high performance plastic.
The two removable parts, the front cover and an access point to an SD card, are rubber sealed.
The base connectors for I/O and Ethernet are from Harting - their M12 X-coded Series.
For USB, they use Harting Push Pull USB 3 connectors.
image source (edited): Harting MICA USB product page
The PCBs are mounted on a thick aluminium base plate.
image source: HARTING HAIIC MICA Bausatz, Abb. 9: Platinentraeger
When you supply your own add-on hardware, there are detailed instructions- including technical drawings of the size of your extension board.
On the photo below (in the Electronics section), you can see a proto extension board. That's what you get when you have a base MICA.
In the MICA USB version, this part is replaced by a PCB with the 2 external USB connectors.
image source: HARTING HAIIC MICA Bausatz, Abb. 4: Bestückter Träger und Trägerplatte
The processor is an unspecified 1 GHz ARM *1.
It has 1 GB of ram and 4 GBs of flash. You can (I did) add a 32 GB micro SD card.
The compute specs aren't that different from other ARM Linux boards. But the build is.
The MICA is built to spend it's life in harsh industrial conditions - and certified for that.
Inside the box, everything is mounted to survive shocks. The PCB only has components that are designed to survive shocks and drops. Nothing that's prone to vibrations, no components flapping around in the breeze.
And everything is mounted inside in a way that it can survive the conditions specified by those certification's conditions.
This module is available in every MICA products. It's part of the base. But - at least in the USB edition I'm reviewing - it's not the essence of this box.
It's a great module though. A set of I/O lines that are industrial hardened and compliant.
They support the usual industrial levels of 12 and 24 volt and are certified for use in trains (where the lines can go up to 33 V).
Industry I/O isn't the same as microcontroller I/O. Standards are different and ways of workings are different.
On the MICA, the I/O is provided by an Infinion (for you Europeans: Siemens, and for everyone: a company that knows how to build industrial compliant drivers) SPIDER controller.
This device is worth of a separate post - and I'll write one.
image source: Infineon datasheet TLE7239SL SPI Driver for Enhanced Relay Control
It's a SPI device, a neat module for industrial I/O handling.
Even though Harting don't promote this aspect, it's an important aspect of an industry capable controlling device.
All eight can be used as input and output.
There are three configurations divided over the eight I/O lines: high side (4), low side and dual side switching (each 2).
image: two USB connectors (2nd unused but protected), GPIO and network
You don't talk to the base OS. The MICA is managed via a web console.
Management can also be scripted. There's an API.
Next to the usual user management and network setup options, the console is also the place where you load new containers.
You can configure them, switch them on or off, and export them.
Access to all devices (objects in the Linux /dev folder) can be configured per container.
You also reboot the system and update the firmware via the console
image: action picture of my MICA console, with several modules disabled and custom containers installed
The home page gives an overview of the installed modules and containers. The screen capture above is a life example of my setup.
You can see several containers with Roadtest in the name. Those are custom ones based on Harting ones.
In some documentation, they are also called microservices.
On the MICA, containers are the way you build applications. You pick a good base container, develop your solution and export that container as a deployment block.
Harting promotes to limit the amount of logic to "one unit". You should not build a whole Linux ecosystem in one block.
A good example of that is that NodeRed, MQTT, databases and the GISSGateway are all separate Linux containers, while on a typical single board computer, you'd install all on the same Linux.
I've tested these:
This is part of the example Bosch CISS sensor example. It polls the sensor at regular times and posts the telemetry to an MQTT server.
The MQTT broker can be the one provided by Harting or another one.
image source: Bosch CISS USB Protocol
The communication between MICA and CISS is serial, over USB.
This container seems to be intended as a demo block. I tried to use it as a starting point to develop my own implementation but that was not successful.
I made a custom one from scratch. More on that in the Java8 section.
This is a typical Node Red configuration, with editor and the usual blocks.
The Node Red dashboards are accessible from the MICA web console.
The flow that reacts on the CISSGateway MQTT messages is installed out of the box.
image: action picture of a Node Red process integrated with a secure MQTT server
I've used that container to talk to an alternative secured MQTT server and to test a custom dashboard.
The links are at the end of this review.
note: for this container I had to enable IPv4 or the node red editor and dashboard would not work. I haven' tested if I could resolve this by making IPv6 external vs internal.
Like the Node Red one, this module is also a base setup. A MQTT server with connectivity over http.
You can adapt the MQTT server by providing your own config.
In the Bosch sensor demo, this broker is used by default as the exchange mechanism between CISSGateway and NodeRed.
In my roadtest, I've replaced this container with a custom one. Again, the link is at the end of the post.
image: action grab of these three containers working together
They have a good mix of Linux base containers, from very light to rich: Busybox, Debian Stretch and Jessie.
The Busybox has the smallest footprint. This one is ideal if you want to run Linux custom programs, such as native binaries.
By default, Busybox has little options and libraries installed. If you are depending on many packages, you may want to go for the Strech container.
I successfully cross-compiled a "Hello, world!" example on Windows and ran it on a customised Busybox.
Debian Stretch is a more elaborate base. It's easier to add components t this one with a package manager.
A good choice when you need a standard Linux environment to run your software.
I used this one as base for a custom MQTT broker. I also installed a Java runtime on one as alternative to the standard Java8 container, and executed and debugged custom C programs.
Debian Jessie is comparable with what you get on a BBB or Raspberry Pi. That's the completest Linux option.
This one is not intended as a base for custom containers - it's intended for development use.
If you intend to develop on the MICA itself, you could use a Jessie container to install the GCC tools or a Java Development Kit.
Because I haven't used the MICA as the development computer (I compiled all code on a Windows PC), I haven't extensively used the Jessie container.
 |
image: size of the 3 Linux options after install
This ready to use block allows you to share the internal SD over network - with security.
You don't need it to connect to the SD card from other containers.
The SD card is placed in the backside of the MICA. The area is protected against water with a rubber sealed cover.
I'm not sure if an SD card holder with card mounted can survive the same intensity of shocks and vibration as what the MICA is certified for.
Further instructions on how to use the card in a container and on your network: HARTING MICA: SD Card as Shared Storage.
This is a demo module that works together with the MQTT broker.
It lets you configure each I/O line.
When a line is configured as output, the module will subscribe to an MQTT topic. When a message arrives, it will then set the output based on the payload, and show the status in the web console.
When it's set as an input, the module will react on a change at that input and send a message to an MQTT topic.
This is a ready to use Java 1.8 runtime.
Harting flags this one production ready, while most other containers are marked for development or demo use.
java version "1.8.0_162" Java(TM) SE Runtime Environment (build 1.8.0_162-b12) Java HotSpot(TM) Client VM (build 25.162-b12, mixed mode)
I used this container as runtime for my custom Bosch CISS Java program.
There is no JDK installed. This is not inteded as a base for development. If you want to compile your Java code on the MICA, go for the Jessie container and install a JDK.
I compiled my example on Windows.
Although you download it from the container repository, this isn't an installable container. It's a GPIO library that you can use with C on one of the Linux containers.
On that linux container, you install it (instructions in the documentation). The installer tkakes care that libs and header files are placed in the appropriate locations.
I used this library in a C program. Info linked to at the end, and discussed in the Development section.
This is a pure demonstration block, as a source of inspiration for dashboard designers.
image source: Harting container documentation
The dashboard is static, unlinked to input signals or measurements.
I think Harting made it to have a beautiful screen display in the demo boot on industry fairs.
Harting focuses on Python, Java and C as programming languages in the documentation and examples.
These are also the ones most supported by the containers.
As backbone, you have the MQTT and Node Red options reviewed above. There are also storage servers (Hadoop, MySQL and the NAS one).
You can develop on the MICA. My preference when developing for embedded devices is to not do that.
These boxes are sized to execute code, not as development environments.
For Java, developing on separate development computer is straightforward.
You don't have to fiddle with cross-compile toolsets. You can just use your Java development computer and build the code there.
Because the MICA uses USB to talk to it's extensions (even the custom PCB that you can mount in the box), you can do the full develop and debug on your development box - even if it's a Windows machine.
Image: action capture of a Java program talking to the Bosch CISS sensor on a windows laptop. The compiled code works as well in the Java8 container.
For C/C++, I've set up a cross-compile environment.
I develop the code on a Windows PC, with Eclipse as IDE.
Compilation of the Linux binary also happens on Windows.
When debugging, Eclipse automagically uploads the binary to the MICA, starts a debug server there and you can step through the code from the IDE.
When you prefer to develop on the MICA itself, the Debian Jessie container is a good environment.
Although a very popular option on single board computers, I didn't do Python development. Other roadtesters will review this.
Overall, MICA offers a good mix of tools. And you can choose your own options, as long as you can make it run on Linux.
Not everything was 100% OK. My review is positive - but I did have issues and gripes.
The MICA has good measures to build secure solutions. All containers are based on Linuxes with good pedigree.
There's also an excellent mechanism to restrict access to pluggable hardware. The basis infrastructure is there.
Securing containers on the other hand is lightly touched. They deserve the same attention as other functional aspects.But examples and containers often do not implement base security.
This is where I think Harting is dropping the ball. It's a subject that's virtually untouched.
E.g., the MQTT and Node Red container are not secured. If you know the default addresses of these two services, you're in.
The Node Red container gives you the right access to improve the setup and make it secure. I didn't manage to get enough access to the MQTT container though. I couldn't install the necessary certificates to secure it.
Surfing to http://nodered-<yourdevice>:1880/#flow/36bcf7fe.9d0078 allows you to edit and deploy Node Red flows, including changing the servers they talk to.
Surfing to http://nodered--<yourdevice>:1880/ui/#/0 gives you access to all collected data reported to a dashboard.
Connecting a MQTT client to MQTTRoadtest-<yourdevice> , port 1883, allows you to subscribe or publish to any topic, potentially talking to hardware (if the GPIO Container is deployed).
If you're an implementation partner - or a company deploying the box - you'll need a MQTT and Node Red security expert to either secure the provided containers or build secure containers yourself. The examples don't stand the test of intrusion.
The CISSGateway and GPIO example containers will not work if you implement your own secure MQTT service, without extensive changes.
The documentation does not elaborate on secure containers or improving security in the provided containers.
I always hope that vendors - knowing that IoT and IIoT is criticised for neglecting the security topic and providing limited direction to implementers - would step up. For Harting there's significant stepping-up to be done.
I didn't have many issues. The MICA hasn't ever crashed and even during active development the stability was excellent.
There are issues with the USB stack and the Bosch CISS sensor though. It seems that there are stability issues, and the sensor would sometimes disconnect as /dev/ttyACM0 and then connect as /dev/ttyACM1, during execution.
I'm not the only roadtester that had this issue.
The developer can't configure Linux in a way it always pairs under the same name.
The device is mounted before your containers start, and you have no say on how the CISS is mounted.
Configuring fixed names has to be done on the base (firmware) Linux of the MICA and only Harting has access to that.
This at-runtime switching between ttyACM0 and ttyACM1 does also not work good with the device security management. I can elaborate on that if you're interested.
Getting Started guide, examples and container versions aren't in sync. The Getting Started example and documentation with the Bosch CISS sensor is dependent on a particular combination of container version. It didn't match the versions installed on the MICA from factory, nor the latest version of each container involved.
It's not a big deal (MQTT topic and Node Red flow mismatch - easy to fix but examples won't work) but it impacts the first impression.
I'd suggest Harting publishes a Getting Started adapted to the latest container releases every time one of the involved containers change.
This container says it's running OpenJDK, but when I check, it seems to be the Oracle one:
java version "1.8.0_162" Java(TM) SE Runtime Environment (build 1.8.0_162-b12) Java HotSpot(TM) Client VM (build 25.162-b12, mixed mode)
When I installed an OpenJDK JRE myself on a Debian Stretch container, I got:
openjdk version "1.8.0_212" OpenJDK Runtime Environment (build 1.8.0_212-8u212-b01-1~deb9u1-b01) OpenJDK Client VM (build 25.212-b01, mixed mode)
This one doesn't allow me to have enough access to secure it. No putty or file access, and I'd at least need file access to install certificates.
Widest open MQTT install possible.
Only works with unsecured MQTT, I could not find the sources in that container to jumpstart from and make a secure implementation
A very good implementation, but using it as a good startpoint would require the source code and build instructions. I could not find them.
The way of adapting a Busybox is via sources. That's how you adapt these small footprint Linux boxes.
I got by with downloading and unzipping the Harting container, adding binary files, then Compressing and deploying. But that only works for limited use cases.
Widest open Node Red install possible.
Fortunately, this one has the right setup for you to adapt and improve.
When listening to the MQTT container that's factory installed, allows open access to the I/O lines.
While it can connect to a different MQTT broker, there are only provisionings to connect to an open MQTT server. No support for password or certificate..
There are partners in the MICA network that deliver certified solutions running on this device. If you (like me) are involved in shop floor data collection and industrial monitoring, there are capable solutions and partners in that network.
If you are interested in safe IIot: there may be a business out there to deliver safe-to-start containers.
If you are a MQTT or Node Red expert (note to self: become one, and note to you: I thought about it first) , start your business and provide those Harting network companies with some safe-from-the-start containers - with implementation guidelines.
*1 Harting haven't published it in the product specification.
Top Comments
That's a really excellent review Jan Cumps! I think it is a very fair representation of the product.
I'd better do some work to get mine ready!
Your blogs and other help have been invaluable.
…Very well done and through RoadTest. There is certainly a lot of valuable info you have provided on this product.
These days, it seems like trying to Containerize everything is hot topic; everything from…
Yeah, I agree that Harting did a good job.
Looks like Wind River is jumping on the Docker Container and Kubernetes Band-wagon as well.
https://www.embedded-computing.com/news/wind-river-linux-adds-docker…