Industrial IoT Project

I'm using the fischertechnik system to build industrial models. The official fischertechnik controller features an I²C bus. Ten years ago, I decided to design my own advanced sensors and that is how I started to explore the embedded world.

Now, I am back to the fischertechnik system and I am looking for a better way to manage the models, especially the large ones like the New Magasin.

I devoted the section Dealing with very large models to discuss the many difficulties raised by such models.

Contrary to Lego Mindstorms where sensors and actuators are closed but software open, fischertechnik relies on standard hardware for the sensors and actuators, but keeps the controller and the software closed.

The model pictured here includes 27 sensors and 28 actuators managed by seven processes plus one service. It requires three official controllers to provide enough inputs and outputs.

I explored two options for the software:

Parallel processing: one controller performs all the tasks and uses the inputs and outputs of the other two;
Distributed computing: each controller performs a set of tasks and synchronises with the other two.

Alas, those options face many issues.

Hardware: as the controllers are centralised, ten of meters of lengthy cables make review and maintenance impossible.
Software: complexity grows exponentially with no possible simulation for a single process and no decent debugger from the official IDE.
Communication: the radio for synchronisation isn't reliable.

What's new?

The sensors and actuators I've designed, called smartDevices, include an embedded micro-controller: they process high level commands and send filtered measures. Because they can be physically isolated and they offer a limited set of interactions, debugging is now very easy.

IoT seems to be mature enough now, with solutions I could leverage to manage large models.

General idea

The general idea would be to use...

...a limited set of controllers specialised on given tasks with the corresponding I/Os...
...connected by radio with low power requirements...
...to a central hub running on a local server...
...exchanging high-level commands and messages.

Features

A limited set of specialised controllers...

Some parts of the industrial models, like the conveyor belts, are highly standard. The specialised controllers are close to their sensors and actuators, perform a limited set of tasks and interact through dedicated drivers.

...connected by low power radio...

WiFi brings an easy set-up with MQTT with QoS thanks to the TCP/IP stack at the cost of high power consumption. Bluetooth is low power but seems over-engineered and prone to interferences. Sub-1 GHz is low power but relies on proprietary stacks.

...to a central hub running on a local server...

The central hub ensures the high level synchronisation of the different processes and provides other services, like a dashboard or connection to other networks.

...exchanging high-level commands and messages.

The radio protocol should include an application layer to manage messages collision and ensure delivery of messages (QoS). Topology could be either hub-less (mesh) or hub-centric (star).

Posted: 24 Oct 2020
Updated: 26 May 2021