OneOS: IoT Platform based on POSIX and Actors

Recent interest in Edge/Fog Computing has pushed IoT Platforms to support a broader range of general-purpose workloads. We propose a design of an IoT Platform called OneOS, inspired by Distributed OS and micro-kernel principles, providing a single system image of the IoT network. OneOS aims to preserve the portability of applications by reusing a subset of the POSIX interface at a higher layer over a flat group of Actors. As a distributed middleware, OneOS achieves its goal through evaluation context replacement, which enables a process to run in a virtual context rather than its local context. 1 Motivation and Approach The Internet of Things (IoT) is now a reality. With an increasing number of smart devices, the IoT topic of the year 2018 was IoT Platform [13]. A recent interest in Edge/Fog Computing (i.e., the concept of taking the workload from the cloud and spreading it across the IoT network) has posed new challenges for IoT platforms to evolve into more general-purpose systems, providing the flexibility to deploy arbitrary programs on a broad range of devices. Therefore, we need to design an IoT platform that can fully utilize the network’s compute resources for general-purpose workloads in addition to the cyber-physical workloads. There are two high-level goals of a general-purpose IoT platform: 1 to provide a dependable computing infrastructure, 2 to provide a programming environment for a user (e.g., an application developer) to leverage the distributed computing features of the platform. Building and maintaining a coherent software infrastructure for an ever-increasing diversity of devices is a massive effort. Platform-specific details need to be under strict bookkeeping, and different programming abstractions and languages need to be reconciled. Traditional reliability techniques become inadmissible due to the heterogeneity and the resource constraints of the devices. Furthermore, the solution must be future-proof to account for the long life-cycle of IoT devices. An IoT platform must meet these challenges gracefully and reduce the complexity that a user has to deal with. Figure 1: OneOS operates over a network of abstract Actors, as opposed to a bare-metal Von Neumann Machine We observe that operationally, an IoT platform is analogous to an Operating System (OS); it provides common services and I/O interfaces for user programs, and runs programs under a schedule and policy. However, unlike a Host OS, which manages the local hardware resources like CPU and memory, an IoT platform typically manages a heterogeneous network of self-contained runtime systems. Thus we propose a design of an IoT platform, which we call Overlay Network Operating System (OneOS), operating in the application layer over a flat group of abstract Actors [21] to provide a single system image of the computer network. As the model of the underlying machinery does not directly involve low-level resources, the focus of OneOS differs from a Host OS. OneOS addresses higher-level concerns regarding distributed computing: scheduling of programs on different runtime systems, coordinating inter-process communication (IPC), providing a mechanism for locating various resources within the network, storage of data, and providing an API to the user. Existing IoT platforms and other distributed computing frameworks provide the aforementioned functionalities at the cost of programmability; they often require the user to use a specific API or adopt a certain programming paradigm. Alternatively, we adopt the POSIX [1] interface, which already provides abstractions sufficient for building a distributed system. Adopting a living standard that has stood the test of time can make it easier to maintain the system design and preserve the portability of applications. Previous research on POSIX kernels have shown challenges in managing low-level hardware resources during run-time [33] and when writing the kernel itself [9]. We avoid these issues by working with highlevel language runtimes, which handle the low-level tasks like garbage collection, and selecting a subset of POSIX interfaces relevant to distributed computing. By mapping abstractions like I/O streams over an Actor network, we can run existing programs without modification. Reading a value from a sensor and writing it to a file should be as simple as a single line of command: cat /dev/sensor1 > sensor1.log. To actualize this concept, we highlight the following insight: all we need to do is to adjust the operational semantics of a program execution – we must interpret a program in a distributed context, rather than in the local context.