Most Powerful Open Source ERP

Open Edge Computing for Industry 4.0

  • Last Update:2021-04-28
  • Version:001
  • Language:en

Nexedi - Profile

Nexedi World Map
  • Largest Free Software Publisher in Europe
  • Founded in 2001 in Lille (France) - 35 engineers worldwide
  • Enterprise Software for mission critical applications
  • Build, deploy, train and run services
  • Profitable since day 1, long term organic growth
Nexedi is probably the largest Free Software publisher with more than 10 products and 15 million lines of code. Nexedi does not depend on any investor and is a profitable company since day 1.

Nexedi - Clients

Nexedi References and Map

nexedi.com/success

Nexedi clients are mainly large companies and governments looking for scalable enterprise solutions such as ERP, CRM, DMS, data lake, big data cloud, etc.  

Nexedi - Free Software Stack

Nexedi Software Stack

stack.nexedi.com

Nexedi software is primarily developed in Python, with some parts in Javascript.

Edge Computing

 

History

 

Edge Computing

Edge Computing
 

Industry 4.0

 

German Industrial Policy

The term "Industry 4.0" is double sided: political and technological.

The political nature of "Industry 4.0" is easy to grasp: the term was introduced in 2011 at a Hannover Fair in the presence of Chancellor Angela Merkel . As a world super power in industry, Germany must embrace digital innovations to maintain its leadership compared to fast growing and massively subsidised industries in countries such as China. Many industry leaders in Germany now privately acknowledge that Chinese industry has become very innovative and is able to produce high quality products. Chinese industry improved tremendously over the last decades thanks to modern machinery that was actually paid by the government through "free loans" that do not need to be reimbursed. China industry's competitiveness is no longer related to labour costs or taxes (both are high) but rather to ability of Chinese entrepreneurs to benefit from such "free loans" (billions of Euros) through good social relations with the communist party. With Industry 4.0, Germany can now compete against subsidies in China and at the same time respect WTO agreements that ban subsidies except for R&D.

The German government invested 200 million dollars for Industry 4.0 research across government, academia, businesses. This new industry is an integral part of the 2020 High Technology Strategy for Germany, which wants to maintain its leadership in technological innovation.

Cyber-physical Systems

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.

Industry 4.0 as Computer Science

General Interoperability Information transformation Technical assistance Decentralised decisions
Production process Real-time stochastic simulation Big Data store Predictive maintenance Smart tooling
Smart manufacturing execution Production macro-planning Personalised production  
Logistics Sales previsions and stock optimisation Logistics macro-planning Road Usage Charging Big Data store
Customer retention Customer behaviour Analysis Short feedback loop Big Data store  
Product configurability Customer transparency Mobile ubiquity  
Smart machine / product
and associated services
Autonomic code deployment (signed) and lifecycle at the Edge Secure Boot Big Data store
Device Management Trusted communication Resilient communication Virtual proxy
Transactional communication Smart SDR controller Data collection Network isolation
Autonomous maintenance and optimisation Assisted repair and maintenance Autonomic self-optimisation  

Industry 4.0 translates into multiple computer science and digital technologies. Some are quite general:

  • Interoperability connection and communication between machines, devices, sensors, people, etc. (a.k.a. Interconnection);
  • Information transformation : maintain a virtual copy of the physical world (a.k.a. Information transparency);
  • Technical assistance : support humans for making informed decisions and solving urgent problems, physically support humans for unpleasant, exhausting and dangerous tasks;
  • Decentralised decisions : machines make decisions and perform tasks as autonomously as possible.

Some can be categorised using four groups with specific goals.

  • Production process: more efficient production processes and cost savings thanks to resource optimisation;
  • Logistics : more efficient flows of goods and information, lower stocks and plant efficiency as an enabler of new business opportunities;
  • Customer retention:  closer ties with customer and more closely targeted consideration of customer needs;
  • Hybrid products and the associated smart services : data collection for machine monitoring, fault rectification, repair and maintenance via smart services bundled into "premium" products with higher prices ("German quality").

Equivalence between Industry 4.0 and computer science is illustrated in the table bellow.

OPC UA: PubSub TSN VW

https://open62541.org

 

Industry 4.0 Open Source / Open Hardware Meetup @Fraunhofer IAO Stuttgart

https://www.nexedi.com/NXD-Industry40.Meetup.Programme.2018
 

Olimex

https://github.com/OLIMEX

 

MariaDB Foundation

https://mariadb.org

 

Slowtec

https://github.com/slowtec

 

Open Compute Project - OCP

 

Linutronix

https://github.com/Linutronix

 

Stuttgart Libre Software Stack for Industry 4.0

Component General Production Logistics Customer Smart Machine / Product
Nexedi ERP5 Inf. transform. Personalised
Macro-planning
Macro-planning
RUC
Product configurability
Transparency
 
SlapOS Dectrl. decision Smart tooling
Smart MES
  Short feedback loop Autonomic Edge
Virtual proxy
Autonomous maint.
Device Management
Network isolation
Self-optimisation w/ GPU
Wendelin Inf. transform
Tech. assist.
Predictive maint. Sales previsions
Stock optimisation
RUC
Behaviour Analysis
Short feedback
Device Management
Autonomous maint.
JIO Interop   RUC Mobile ubiquity  
re6st Interop       Resilient communication
ManPy Inf. transform
Tech. assist.
Discrete simulation      
Caucase         Trusted communication
RenderJS       Mobile ubiquity  
NEO   Big Data store Big Data store Big Data store Big Data store
Pyodide Tech. assist.        
ARM fluentd Interop Predictive maint.
Smart tooling
Smart MES
    Data collection
Autonomous maint.
embulk Interop        
Linutronix Elbe RFS         Secure Boot
Jailhouse         OS Isolation
SDS Linuxboot         Secure Boot
Slowtec tokio-modbus Interop        
MariaDB connect Interop        
Keyveo BabylonJS         Assisted 3D repair / maint.

 

SlapOS: Open Edge Computing and Orchestration

 

Agenda

  • History
  • Design
  • Success Cases
 

History

 

SlapOS: (one of) the first edge computing systems

https://www.cio.com/article/2417512/servers/vifib-wants-you-to-host-cloud-computing-at-home.html

We've been deploying edge computing at Nexedi since around 2008 with SlapOS.

Everyone has a different notion of edge computing. We tried to define them in this article: Five Evolutions of Cloud Computing "https://www.nexedi.com/NXD-Blog.Five.Cloud.Evolution". However, Edge Computing is kind of buzzword that covers many old ideas of distributed computing that recently became more widely accepted.

Why don't you use OpenStack?

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.

Why don't you use LXC/Docker?

  • Not portable across Linux distros
  • Not supported outside Linux
  • Still a bit unpredictable on Linux
    ~ $ free -h
        

https://www.nexedi.com/NXD-Blog.Docker.SlapOS.Nano.Container.Elbe

 

Design

 

Everything is a Service

  • A database service
  • A kvm service
  • A routing service
  • An HTTP cache service
  • An ERPservice
  • etc.
 

SlapOS: Service Operation Automation

    
            ~ $ slapos request mariadb my_db
            ~ $ slapos request kvm my_vm
            ~ $ slapos request re6st-registry my_registry
            ~ $ slapos request cdn my_cdn
            ~ $ slapos request erp5 my_erp
          
        
 

Service Unification from Edge to Space

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).

Design Goals: Automate Service Lifecycle

  • catalog (of services)
  • build
  • test
  • ordering
  • provisioning
  • configuration
  • orchestration
  • monitoring
  • issue tracking
  • accounting
  • billing
  • disaster recovery

We wanted our solution to cover all aspects of the lifecycle of service:

  • catalog of available services (appstore);
  • build;
  • ordering;
  • provisioning;
  • configuration;
  • orchestration;
  • monitoring;
  • issue tracking;
  • accounting;
  • billing;
  • disaster recovery (incl. ability to rebuild everything after 10 years):

Design Goals: Security and Resiliency

  • insecure network
  • unstable network
  • unstable hardware
  • unstable electricity
  • vanishing code sources

http://iwgcr.org/

And we wanted our solution to be take into account "real world" features of public infrastructures which we had observed and made statistics of:

  • insecure network (anyone can spy it);
  • unstable network (packets are lost, connectivity is lost);
  • unstable hardware (any component can crash);
  • unstable electricity (electricity shortage is always possible).

The article "Downtime statistics of current cloud solutions" (http://iwgcr.org/wp-content/uploads/2013/06/IWGCR-Paris.Ranking-003.2-en.pdf) should give a good overview of the lack of resiliency of cloud, networking and electricity no matter who is the supplier.

Promise Based Minimalist Architecture

  • Master: ERP5 (promise definition, ordering, provisioning, accounting, billing, issue tracking)
  • Slave: buildout (promise execution, build, instantiation, configuration, monitoring)

https://en.wikipedia.org/wiki/Promise_theory

So, we used buildout (http://docs.buildout.org/en/latest/) as the base for our service descriptor language and ERP5 to keep track of "service lifecycle" after we found out that any edge or cloud system can be made of two components: a devops and an ERP (see "SlapOS: SlapOS: A Multi-Purpose Distributed Cloud Operating System Based on an ERP Billing Model" https://ieeexplore.ieee.org/document/6009348). 

For resiliency, we based all our design on the idea that resiliency must be implemented with software and should rely on redundant infrastructure on redundant sites with redundant suppliers. However each site or hardware does not need to be redundant.

This approach was quite successful. By sticking to a very simple and minimal architecture, we could achieve with a small budget what huge community projects such as OpenStack still fail to achieve after 10 years. And we could do much more, because our architecture was more generic.

re6st

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.

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:

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

Success Cases

 

Success Case: Grandenet Global CDN

http://www.grandenet.cn/

HTTP2/QUIC CDN all over the world including in China (we have a license for that)

Success Case: Factory-in-a-box

automated deployment of "smart factory box" for some European automotive company in new factories located in Africa and Asia (all kinds of services can be remotely deployed starting from ERP, CDN and soon MES)

Success Case: LTE/NR SDR NMS

https://www.nexedi.com/NXD-Document.Press.Release.NMS.Preview.MWC.2018

Success Case: Data Collector

  • fluentd multi-protocol buffering of IoT (on 400 wind turbines in Germany, on GPU powered smart sensors)

Success Case: WebRunner IDE

  • Web based IDE (to develop all projects that Nexedi sells to big customers)

Success Case: Rapid.Space

https://rapid.space

https://beta.rapid.space/ is a high performance, low cost cloud infrastructure that provides:

  • big servers;
  • CDN;
  • IoT buffering.

It is available in China  in addition to Europe. It is based on SlapOS and Open Compute Project (OCP) hardware, the same as the one used by Facebook.

Success Case: Teralab

https://www.nexedi.com/success/slapos-IMT-Documents.Teralab.Success.Case

References

You can find more articles related to SlapOS:

Backup Slides

 

Design Goals: Unify Service Description

  • no matter where
  • no matter when
  • no matter what
  • no matter which distro or OS (POSIX)
  • no matter which version of distro
  • no matter which architecture
  • no matter complexity
  • with real time, high peformance and resiliency support
  • and at lowest possible cost

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).

Nano Containers

  • declarative
  • bare metal
  • multiple versions
  • multiple instances
  • no superuser needed
  • portable across Linux distributions (unlike Docker)
  • portable to other POSIX OS (Android, FreeBSD, etc.)
  • (option) source cache (encouraged)
  • (option) binary cache
  • (option) virtualisation
  • (option) name spaces
  • (option) containerisation (discouraged)
 

Linuxboot

https://www.linuxboot.org/

LinuxBoot is a firmware for modern servers that replaces specific firmware functionality like the UEFI DXE phase with a Linux kernel and runtime. Why? Improves boot reliability by replacing lightly-tested firmware drivers with hardened Linux drivers. Improves boot time by removing unnecessary code. Typically makes boot 20 times faster. Allows customization of the initrd runtime to support site-specific needs (both device drivers as well as custom executables). Proven approach for almost 20 years in military, consumer electronics, and supercomputing systems – wherever reliability and performance are paramount.

Future

 

SlapOS Roadmap

  • Jupyter-lab
  • Secure Boot: ELBE RFS
  • Software Defined Sensor: PREEMPT_RT
  • Edge Gateway: OPC-UA, DDS
  • Radio Router: HCCA, TD-Wifi, NR