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:
- Find an SSL library that'll fit both footprints
- Configure it to have a coherent set of modern ciphers compatible across the two ecosystems
- Get the various protocol libraries to build against the chosen SSL library
- Create key provisioning tools that can work across the two ecosystems
- 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.
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.
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.
The Project can be divided into two different parts, license-wise: First Party and Third Party.
- First Party is software created by the Project from zero
- Third-Party is software reused by the Project (such as libraries, components, tools, and other Software Content) that is patched according to the "Upstream First" principle.
First Party software is licensed under
Apache License, Version 2.0
Third-Party Software is constrained by the choice made upstream and it can be in many different licenses. Due to its nature, see [background] for more detail, Eclipse Oniro reuses many components from third parties just to work on a bare minimum environment, that it needs to patch and adapt for its special requirements and needs. This involves -- unlike many other projects -- that both the amount of software that is utilized and the number of licenses is likely to be larger than usual.
This list of licenses would include both non-copyleft and copyleft licenses, including the GNU GPL family.
The Initial Contribution is licensed under the Apache License, version 2.0. This is a precise choice in order to permit the largest implementation of the Project in embedded software devices with the license that still preserves the open-source nature of the Project, gives some form of protection from patent ambushes, but leaves contributors with the largest freedom to reimplement the software in the unrelated project, including for writing Oniro-compatible applications and hardware objects with different operating systems. It shall be noted that Apache 2.0 is inbound compatible with Eclipse Public License 2.0.
For third-party software, the upstream constraints on the licensing dictate both the code hosted and the provided patches, which need to be under the same or compatible license, but preferably under the original license in order to increase the chances that the patch is accepted and adopted upstream.
It might be worth noting that the above could include non-OSI approved licenses, although the general policy of the project is to avoid them as much as possible. Conversely, in the project's code no proprietary code is anticipated, although in order to interact with hardware certain platforms could be forced to use proprietary drivers: provided that this would be entirely the choice of those adopting the Eclipse Oniro Core Platform for their own projects and it will not be part of Oniro which will use a standard generic hardware platform as main development basis.
Other than that, no special legal issues are foreseen.
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.
Eclipse Oniro Core Platform will work on the following key features over the next year to address market gaps and partner requirements:
- A complete OTA update solution for Linux and Zephyr including a reference integration for device management for ODMs.
- Monthly releases for the 1.0 release to address existing security issues.
- Pre-built binaries for Reference HW platforms
- Eclipse Oniro Core Platform will work towards implementing a future shared set of specifications with OpenHarmony that will be defined in a separate project
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.
The following individuals, organisations, companies and projects have expressed interest in this project:
- SECO
- Linaro
- Array
- NOI Techpark
- Synesthesia
- Huawei
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.
- Log in to post comments