Creation Review

Type
Creation
State
Successful
End Date of the Review Period

Reviews run for a minimum of one week. The outcome of the review is decided on this date. This is the last day to make comments or ask questions about this review.

Proposal

Eclipse Oniro Core Platform

This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process) and is written to declare its intent and scope. We solicit additional participation and input from the community. Please login and add your feedback in the comments section.
Parent Project
Proposal State
Created
Background

Currently, the IoT world is highly fragmented and characterized by vendor lock-ins that do not benefit anyone - users, content creators not even device makers. The business driver behind today's implementation of IoT devices and architecture is that to drive and monetize data in the cloud. Simply put, IoT does not work without a working connection to one of the very few cloud services providers, which capture most of the IoT revenue. The final outcome is that IoT devices are not able to smoothly integrate with each other, resulting in bad user experiences. Additionally, device makers struggle to maintain their own custom software and operating system distributions for their IoT devices, resulting in poor quality and security and entailing duplicated development costs (every IoT device maker is reinventing the wheel when it comes to the operating system part of their IoT devices).

Further to this, and due to the fragmented nature of the IoT market, content and applications are not portable across different types of devices, regardless of their brand, model, make. The fragmentation at the operating system level leads to fragmentation at the application level.

IoT products may be broadly classified into two categories - either a device with limited compute capacity, typically a microcontroller running an RTOS such as Zephyr or FreeRTOS or a device with higher compute capacity, typically a CPU capable of running a general-purpose operating system such as Linux. IoT projects typically focus on one of these two device categories. This approach leads to two classes of solutions for the developer ecosystem with little shared software, policies, and services catering to the two classes of devices.

Furthermore, the kernel running on the actual hardware is only a small fraction of the software required to build a product and provide services on these IoT devices. There is a lot of application code, software configuration, and services related to security, OTA, data storage that could benefit from a coherent view of the two developer ecosystems. Such a coherent product platform makes it easy to build a suite of products spanning everything from a simple thermostat to security alarms, from set-top boxes to internet gateways, mobile phones and tablets, and even servers running in the cloud. One could have the same versions of middleware libraries, compatible protocol suites, security configurations, OTA mechanisms, and a single set of IP compliance tools across the two ecosystems.

As an example, when you decide you want to secure all your network communications out-of-the-box in your product platform, you need to:

  1. Find an SSL library that'll fit both footprints
  2. Configure it to have a coherent set of modern ciphers compatible across the two ecosystems
  3. Get the various protocol libraries to build against the chosen SSL library
  4. Create key provisioning tools that can work across the two ecosystems
  5. Perform interoperability tests

Now repeat this exercise across every key component of the OS -- security policy, networking features, OTA, toolchain hardening, IP compliance tools and you end up with a meta-project that spans and contributes to both ecosystems.

Current solutions are tied to a single vendor implementation and make heavy use of the vendor's proprietary cloud infrastructure for the devices to interact with other devices in the ecosystem thereby creating vendor lock-in around such services. This should be improved with an open-source, non-cloud-centric (the cloud is a citizen, not the king) OS built cooperatively by a community.

Scope

Eclipse Oniro Core Platform provides the essential software and a thoroughly tested "book of recipes" (plus some custom "ingredients") that any device maker can use as a basis to build their own Oniro-based distributed operating system, tailored for their own device and for their dedicated application layer, but compatible and interoperable with any other Oniro-based device.

Developing a new kernel or rewriting existing open source solutions is not the primary objective of the project provided the existing software components are architected suitably for integration into a product.

Description

Eclipse Oniro Core Platform is an open-source project aimed at reducing fragmentation in the consumer and IoT device industry which is interoperable with OpenAtom Foundation's OpenHarmony project. The project aims at fulfilling the vision of "any app running anywhere", where "any app" is achieved via building Oniro as an OpenHarmony compatibile implementation, ensuring interoperability, and "anywhere" is achieved by leveraging the Linux Foundation's Yocto Project tools, technology, and rich ecosystem of support CPUs and middleware.

Eclipse Oniro Core Platform is designed to be a distributed operating system that powers devices regardless of their make, model or size (mobile devices, fitness and health targets, entertainment systems, and so on) and allows them to interoperate and share resources with each other.

Interoperability at the edge is the first goal of the Oniro project, the second goal being that of enabling any application to run on any device.

The value of Eclipse Oniro Core Platform to a developer lies in a consistent, thoroughly tested, set of defaults for the software stack, configuration, security policies, and providing software services essential to create a modern IoT device. OEMs and ODMs can then use the output of this shared engineering while reducing costs and time to maintain all this software stack on top of which their application runs. For the user, Oniro-based devices offer value by seamlessly communicating with each other without needing vendor-specific gateways or bridges and have the ability to create richer user experiences out of a combination of Oniro-based devices.

Eclipse Oniro Core Platform will strive to be a coherent, open-source product platform with consistent defaults that follow industry best practices to allow developers to focus on their applications. Developers will get out-of-box functionalities providing for essential features required for a modern IoT product as part of the operating system. The operating system will receive security updates and there will be OTA mechanisms to deploy these updates to the devices. Furthermore, devices built with Eclipse Oniro will have the ability to seamlessly communicate with each other autonomously to allow for a seamless and richer experience without needing to send data to a cloud-based service provider.

This is done by leveraging the Yocto build system, which is designed exactly for this purpose: providing a standard framework and a standard format for "books of recipes" that can be used by device makers to "cook" custom embedded operating system distributions. In particular, its bitbake-based build system, officially supported BSP layers and thousands of pre-packaged software components to provide the scaffolding needed to provide a consistent interface to developers. The layers and recipes in a Yocto-based project provide the flexibility for Eclipse Oniro to use multiple kernels and enforce consistent policies for package versioning and security while also allowing OEMs and ODMs to tweak the OS settings for their own products if they choose to.

While the Yocto Project and its bitbake build engine allow Eclipse Oniro to glue different ecosystem components and technologies together -- application portability across different geographies, devices, brands, etc. is also achieved by working together with the OpenHarmony Working Group inside the OpenAtom Foundation in order to design, develop and implement an OpenHarmony Compatible Specification. In short, the Any App, Anywhere vision is obtained by combining together the embedded operating system ecosystem and its tools from Yocto Project with the application and content creation ecosystem from OpenHarmony.

In the beginning, Linux will be the OS kernel of choice for devices running on CPUs with more than 128MB of RAM and storage. On devices at the resource-constrained end of the spectrum, Zephyr has the ability to run in as little as a few hundred KB of RAM and storage. Both ecosystems have diverse and active communities and an open governance model. The platform's layered architecture allows the addition of additional kernel options as required by the community, e.g. LiteOS, FreeRTOS.

Why Here?

Eclipse Oniro Core Platform will densely pack a huge engineering effort in comparatively small sets of software to make it work on many different platforms, different flavors of hardware, different use-cases. Not having the luxury of plenty of hardware resources to create various layers of software, the need to face the complexity of ensuring changes do not break hardware compatibility is paramount. Writing good software and testing it in-vitro is not enough. Oniro developers need to continuously test any progress on a large array of target devices, which are believed to be "representative" of the entire gamut of potential adopters.

Only in an industry-oriented foundation, and with the openness and clear mission that Eclipse Foundation offers, a community of independent vendors can get together in a neutral forum and share the efforts in order to create a truly "write-once-run-everywhere" platform that works effortlessly and interoperates without bending to the will of a single vendor that dictates everything, often and firstly to its own benefit.

Project Scheduling

The initial contribution for the Eclipse Oniro Core Platform project is now ready to be transferred to the Eclipse Foundation. We'd like to provision the project on Eclipse Foundation infrastructure as soon as possible to create the first Eclipse Foundation Oniro release and continue future maintenance releases from the Eclipse infrastructure.

Future Work

Eclipse Oniro Core Platform will work on the following key features over the next year to address market gaps and partner requirements:

  1. A complete OTA update solution for Linux and Zephyr including a reference integration for device management for ODMs.
  2. Monthly releases for the 1.0 release to address existing security issues.
  3. Pre-built binaries for Reference HW platforms
  4. Eclipse Oniro Core Platform will work towards implementing a future shared set of specifications with OpenHarmony that will be defined in a separate project
Project Leads
Committers
Amit Kucheria
Andrei Gherzan
Zygmunt Krynicki
Mentors
Interested Parties

The following individuals, organisations, companies and projects have expressed interest in this project:

  1. SECO
  2. Linaro
  3. Array
  4. NOI Techpark
  5. Synesthesia
  6. Huawei
Initial Contribution

Eclipse Oniro Core Platform uses Yocto as its base and intends to keep compatibility with OpenHarmony. Following that choice, Eclipse Oniro Core Platform includes various layers and recipes from upstream Yocto to include various third-party software components into the project. Where needed, Eclipse Oniro may override the configuration of how a software component is built by overriding the default recipe inherited from Yocto. In some cases, additional patches are applied to the component on a case-by-case basis. However, Oniro only uses a small fraction of the software components packaged inside Yocto for the core image and blueprints.

The goal is to be able to share these layers and recipes with OpenHarmony in the future.

As described above, all the recipes and their overrides are licensed under the Apache License, Version 2.0. Patches to software components are licensed under the original license of the software component.

Source Repository Type