The technological nature of "Industry 4.0" can be harder to grasp: it implies a slight change in the organisation of production. If we had to summarise it, we would say that Industry 4.0 is about "autonomous smart tooling for the self-organised and decentralised production of personalised smart products with real-time feedback loop so that quality is continually improved". We can imagine Industry 4.0 as a combination of mobile robots, 3D printers, CNC, 5G networks, workshops and web sites which autonomously organise the complete life cycle of a product (design, sales, production, after-sales, customer retention). We can also view Industry 4.0 as a way to bring back production closer to the consumer, through a very efficient network of inter-connected workshops that are able to deliver highly customised products one by one, just like in Luxury industry but with prices closer to those of mass production in China.

Some industrial technologies are key enablers to this change of the production process. 3D printing is a good example: it is now possible to produce complex shapes using all sorts of high end materials and in very short time without having to invest in a mold. 3D printing of PCB is also now possible and provided by Phytec in Germany. Making sophisticated products autonomously has become easier than even thanks to the Fab Lab movement which shares certain aspects with Industry 4.0. One could say that Industry 4.0 is a way to turn some ideas behind Fab Labs into a high end mainstream industry with a market.

We often get questions such as:

• why don't you use virualisation?
• why don't you OpenStack?
• why don't you use Docker?
• etc.

We usually answer: because they don't work according to industrial grade standards, even now, and because they did not exist in 2008.

The meaning of "does not work" is a bit different for Nexedi and for most open source developers. In Nexedi, we want systems that "work always in the same way and for a very long time", rather than systems that "work sometimes" and are easy to install with a beautiful web site. We want this kind of predictability for everything (build, ordering, etc.). We care more about improving our software than community or documentation. If a solution works but is rejected by most community, we ignore community because we have to serve our customers first (our business model is based on customers, not on venture capital).

The article "Are Linux containers stable enough for production and why Nexedi uses SlapOS nano-containers instead ?" (https://www.nexedi.com/NXD-Blog.Docker.SlapOS.Nano.Container.Elbe) explains for example why we do not use Docker or LXC containers and why we do not plan to use them for ourselves. Until recently, it was very difficult to find anyone who would agree with us (just like OpenStack 10 years ago). But more and more people now understand the problems of binary portability with Linux kernel and its consequence on Docker/LXC containers.

So, we might use "kernel namespaces" with SlapOS.

SlapOS could easily support docker/LXC type containers; we actually already implemented it. But those docker/LXC containers will only work if some strict conditions are met: host OS/Kernel and guest OS/Kernel should be same for example. Sadly most developers do not understand those conditions and do not respect them. It is thus difficult to provide something that works according to our standards.

What mattered to Nexedi when SlapOS was created is that whatever service we would deploy, we wanted to be able to deploy it fully automatically using the same "service descriptor language", no matter:

• where (data centre, on premise, inside an airplane, on a smartphone, inside a sensor, etc.);
• when (today, in 5 years, in 10 years, etc.);
• what (database service, VM service, application sever service, smart sensor processing service, data buffering service, etc.);
• which distro (Debian, Ubuntu, Fedora, CentOS, FreeBSD, SuSE, RedHat, Arch, etc.);
• which version of distro (2016, 2017, 2018, etc.);
• which architecture (bare metal, VM, x86, ARM, etc.);
• complexity (unitary service, orchestration of dozens services);
• real time constraints (no constraint, hard real time).

re6st

re6st was created to fix problems of current Internet through an IPv6 overlay network.

In today's Internet, latency is usually sub-optimal and telecommunication providers provide unreliable transit. There are lots of network cuts. DPI systems introduce sometimes data corruption in basic protocols (ex. TCP). Governments add censorship and bogus routing policies, in China for example. There is no way to ensure that two points A and B on the Internet can actually interconnect. The probability of connectivity fault is about 1% in Europe/USA and 10% inside China. It is too much for industrial applications.

Without re6st, SlapOS (or any distributed container system) can not work. If one has to deploy 100 orchestrated services over a network of edge nodes with a 1% probability of faulty routes, the overall probability of failure quickly becomes too close to 100%. There is therefore no way to deploy edge without fixing the Internet first.

This is very easy to understand in China. But it is also true in Europe and USA (maybe not yet in Japan).

re6st routing provides one solution to that. re6st is available in China (license: 中华人民共和国增值电信业务经营许可证：沪A1-20140091). Nexedi has the right to provide global low latency high resiliency IPv6 network for IoT.

• http://www.grandnet.cn/

In addition to re6st, we use buffering to that we do not lose data sent by edge nodes (gateways or sensors) in case of application server failure for example:

• https://www.fluentd.org/

Both re6st and fluentd are used in all IoT deployments done by Nexedi and based on SlapOS.

• big data infrastructure, see:
  • https://www.nexedi.com/success/slapos-IMT-Documents.Teralab.Success.Case