SlapOS is a hyperconverged operating system (HyOS) that can be used to implement edge computing, big data cloud (IaaS), online service appstore (SaaS), Web based IDE (PaaS), etc. The words hyperconverged or edge may sound like buzzwords, and they actually are after Andreessen and Horowitz announced the end of Cloud Computing. They also refer to precise concepts that have been well defined for a few years already: see the definition of Edge or Hyper-converged in Wikipedia.

Let us have a look of what these words could mean in practice for enterprise applications and then for drone applications.

Hyperconvergence for ERP5

Here is how Nexedi deploys ERP5 (you can read here a complete tutorial). We type the following command line:

slapos request erp5 https://lab.nexedi.com/nexedi/slapos/raw/1.0.48/software/erp5/software.cfg

After this command line has been typed, we get the following result:

The diagram shows how a front end with HTTP caching has been deployed on a flock of edge servers (6 servers on 3 continents). A load balancer with dozens of application servers and three different types of databases (transactional NoSQL, transactional SQL, eventually consistent NoSQL) have been deployed and replicated in 3 different location. Disaster recovery tests are run daily to ensure that clones are consistent replicas of the master instance. The whole logic of deployment and operation including disaster recovery, monitoring and resource accounting has been automated through a single automation scirpt that encapsulates all aspects of this complex system.

Automating deployment, operation and lifecycle of complex systems brings three major benefits: increased quality of operation, sharing of operation know how and cost savings.  

Hyperconvergence for Drones

Here are some examples of what we could achieve with SlapOS in the context of flocks of drones (the term flock referers to Reynold's 1997 article "Flocks, Herds, and Schools: A Distributed Behavioral Model"). Suppose that we type a command line like this one:

slapos request flock https://lab.nexedi.com/nexedi/slapos/raw/1.0.48/software/bear_rescue/software.cfg --parameter-city Rambouillet --parameter-radius 10km --parameter-radio-id 228012176510739 --parameter-flock-count 20

This single command could provision a flock of 20 drones with autonomous software that tries to discover a bear lost in Rambouillet forrest and carrying radio tag that can be identified by its ID value (228012176510739). Drones will fly over the forrest, at an altitude that depends on humidity and on the density of leaves, and identify radio signals using a software defined radio system despite higher signal attenuation produced by leaves and humidity in the forrest.

A simple implementation could consist of:

• planning service running on a bare metal server (hosted by Online for example) that downloads a map from OpenStreetMap and assigns to each drone a different area to fly over with a specific flight plan ;
• flight plan service deployed on every drone to let the drone fly autonomously;
• radio scanning service deployed on every drone to listen to radio signal of specified ID;
• mesh communication service deployed on every drone so that each time drones pass nearby, they can exchange results of radio scan over transient peer-to-peer radio link;
• message synchronisation service that broadcasts any relevant information from drone to drone to datacenter using a chain of transient links.

With this approach, drones can be deployed in any area with poor radio communication yet achieve a well defined flight plan to scan the area in minimum amount of time. Using transient radio communication and message broadcasting protocol (ex. gossip protocol), drones can notify in near real time any important discovery without having to go back to the base.

This example demonstrates two aspects of SlapOS:

• service provisionning is achieved online by SlapOS, whenever drones have access to Internet, and may take seconds to minutes (depending on optimisation) ;
• service operation can happen offline, is completely autonomous, independent of SlapOS API and may be based on real time interactions with latencies bellow one second.

This example could be extended to involve satelites and other connected things as illustrated bellow:

We could imagine in this example that the root service that drives the drones, in addition to downloading maps from OpenStreetMap, could also request:

• image capture from earth observation satellite that can measure leaf density and humidity over a certain area of the forrest;
• image processing that computes optimal flight altitude for every drone based on leaf density and humidity;
• storage service to archive results of radio scanning by drones.

What makes SlapOS architecture quite unique is the fact all concepts are unified through a single API that handles accounting and provisionning of any service on any platform, from embedded sensors with low RAM to NUMA servers with terabytes of RAM or even drones and satellites.

Other applications

Based on this example, we can imagine other applications in which SlapOS could encapsulate the provisionning logic.

• Drone rental or sharing service, where SlapOS is used to manage a drone rental or sharing platform for industrial applications in which customers can easily provision the "mission" assigned to the drone (ex. detect defects in wind turbines);
• Drone appstore, where SlapOS manages a catalog of standard applications for drones that can be monetized and provisionned;
• LTE coverage audit, so that regulation authorities such as ARCEP in France can mesure precisely in which areas LTE signal is available;
• Layered flock attack in which a flock of thousand drones is provisionned with a flight plan designed to resist pulse guns by using one layer of drone as a faraday shield for the rest of drones;
• Drone backhaul in which drones are provisionned with Amarisoft LTE software and cover an area of hundred kilometer long by having one drone route packets for the next drone, thus eliminating the need of terrestrial or satellite infrastructure to deploy a long distance communication backhaul;