diff --git a/overview/about-openharmony.rst b/overview/about-openharmony.rst index c25696bfb91fb742508bab91531d5774ca4db0d0..70902b7f9b4d3b4afed81378b13dfc4618b9f5b9 100644 --- a/overview/about-openharmony.rst +++ b/overview/about-openharmony.rst @@ -1,3 +1,7 @@ +.. SPDX-FileCopyrightText: Huawei Inc. +.. +.. SPDX-License-Identifier: CC-BY-4.0 + .. include:: ../definitions.rst About |main_project_name| @@ -6,58 +10,42 @@ About |main_project_name| System Positioning --------------------------- -|main_project_name| is a future-proof distributed operating system open to you as part of the initiatives for the all-scenario strategy, adaptable to mobile office, fitness and health, social communication, and media entertainment, to name a few. Unlike a legacy operating system that runs on a standalone device, |main_project_name| is built on a distributed architecture designed based on a set of system capabilities. It is able to run on a wide range of device forms. - -Play Video - -- If you are an end user, |main_project_name| integrates your various smart devices to implement fast connection, capability collaboration, and resource sharing - between them. This way, your services can be seamlessly transferred to a suitable device that delivers smooth all-scenario experience. -- If you are an application developer, |main_project_name| adopts distributed technologies to make your application development possible on different device - forms. With |main_project_name|, you will have the choice to focus on upper-layer service logic and develop applications in a much easier and more efficient - way. -- If you are a device developer, |main_project_name| uses a component-based software design to tailor itself to your particular device forms based on their - respective resource capabilities and service characteristics. +|main_project_name| is an ambitious rethink on how an open source collaborative operating system can be run across a variety of device classes - from small microcontrollers with kilobytes of memory to powerful CPUs driving a phone, laptop or even a data center. The goal of |main_project_name| is to evolve a set of builtin system capabilities on top of commodity open source kernels that allows sharing of resources and collaboration across distributed devices of various classes. -|main_project_name| provides multi-programming-language APIs for you to develop applications. You can choose from Java, Extensible Markup Language (XML), C/C++, JavaScript (JS), Cascading Style Sheets (CSS), and |main_project_name| Markup Language (HML). +The development of the these capabilities will happen through an open community project along with other interested parties. -Technical Architecture ----------------------- +- For an end-user, |main_project_name| will integrate the multiple, standalone smart devices owned by the user and allow for fast interconnection, capability collaboration, and resource sharing between them. This way, the individual devices can collaborate to provide better context-aware services than if they were operating independently of each other. +- For an application developer, |main_project_name| will integrate distributed technologies to ease application development across different device classes. Developers will be able to focus on upper-layer service logic and develop richer, collaborative applications more easily. +- For device developers, |main_project_name| will provide reference software blueprints for the key product verticals that will allow them to focus their time on tailoring the OS to their device's resource capabilities and service characteristics. These software blueprints will provide best-in-class practices and solutions to keep the devices secure out-of-the-box. -|main_project_name| is designed with a layered architecture, which from bottom to top consists of the kernel layer, system service layer, framework layer, and application layer. System functions are expanded by levels, from system to subsystem, and further to function/module. In multi-device deployment scenario, unnecessary subsystems, functions, or modules can be excluded from the system as required. The following shows the technical architecture of |main_project_name|. +| |main_project_name| will support APIs in multiple programming languages depending on the constraints of the underlying hardware. Developers will be able to choose from Java, Extensible Markup Language (XML), C/C++, JavaScript (JS), Cascading Style Sheets (CSS), and HarmonyOS Markup Language (HML) to develop applications for |main_project_name|. -**Figure 1 Technical Architecture** +| Technical Architecture +| ---------------------- -.. figure:: figures/architecture.png +| |main_project_name| has a layered architecture built around the Yocto Project and bitbake build system. The Yocto Project is very popular in the embedded Linux community and provides an excellent platform for developing a highly-customizable, cross-kernel operating system. From bottom to top, |main_project_name| consists of the kernel layer, system services layer, framework layer, and application layer. In multi-device development, Yocto provides the capabilities to tweak layers and recipes to remove unnecessary subsystems, functions, or modules as required. Kernel Layer ------------------ -- Kernel subsystem: |main_project_name| uses a multi-kernel design (Linux kernel, |main_project_name| microkernel, or LiteOS) so that appropriate OS kernels can be selected for devices with different resource limitations. The kernel abstraction layer (KAL) shields differences in kernel implementations and provides the upper layer with basic kernel capabilities, including process and thread management, memory management, file system, network management, and peripheral management. -- Driver subsystem: Hardware Driver Foundation (HDF) lays the foundation for an open |main_project_name| hardware ecosystem. It allows unified access from peripheral devices and provides foundation for driver development and management. +| |main_project_name| will support a multi-kernel design out of the box (Linux kernel and an RTOS such as Zephyr RTOS or LiteOS) so that appropriate OS kernels can be selected for devices with different resource limitations. Over time, a kernel abstraction layer (KAL) will shield differences in kernel implementations and provide the upper layer with basic kernel capabilities, including process and thread management, memory management, file system, network management, and peripheral management. -System Service Layer +System Services Layer ------------------------------ -This layer provides a complete set of capabilities essential for |main_project_name| to offer services for applications through the framework layer. The system service layer consists of the following parts: +The System Services Layer will contain the bulk of the differentiating features of |main_project_name|. It will provide a complete set of capabilities essential for |main_project_name| to offer services for applications through the framework layer. The system services layer will add the following features over time: -- Basic system capability subsystem set: Implements distributed application running, scheduling, and migration across |main_project_name| devices. This - subsystem set provides the following basic capabilities: distributed virtual bus, distributed data management, distributed scheduler, utils, - multimode input, graphics, security, and AI. -- Basic software service subsystem set: Provides |main_project_name| with common and universal software services, including common event and notification, - telephony, multimedia, Design For X (DFX), as well as Mobile Sensing Development Platform (MSDP) & Device Virtualization (DV). -- Enhanced software service subsystem set: Provides |main_project_name| with differentiated and enhanced software services, including those dedicated to smart - TVs, wearables, IoT devices, and more. -- Hardware service subsystem set: Provides |main_project_name| with hardware services, including location, biometric recognition, as well as those dedicated to - wearables and IoT devices. - -The basic software service, enhanced software service, and hardware service subsystem sets can be tailored by subsystems, and each subsystem can be tailored by functions, depending on the deployment scenario for a particular device form. +- The protocols and primitives that allow devices to discover each other +- APIs to allow sharing of computing, storage and other resources +- APIs that allow applications to be more context-aware due to collaboration with other devices in the network +- APIs to allow applications to expose business logic as `abilities` that may be integrated into other applications or even used on othe devices in the network Framework Layer --------------- -This layer provides what you need to develop |main_project_name| applications: application framework and ability framework, specific to multiple languages (like Java, C, C++, and JS), Java and JS UI frameworks, as well as multi-language APIs for hardware and software services. The APIs designed for different |main_project_name| devices vary according to component-based tailoring. +The Framework layer will provide an SDK to develop |main_project_name| applications in multiple languages such as Java, C, C++, and JS depending on the target device class and its HW constraints. Application Layer ------------------ +--------------- -This layer consists of system applications and third-party applications. Each |main_project_name| application is powered by one or more Feature Abilities (FAs) or Particle Abilities (PAs). An FA provides a UI for user interaction. A PA has no UI and provides background task processing as well as data access. Applications developed based on FAs and PAs implement specific business characteristics and achieve cross-device scheduling and distribution, delighting users with consistent and efficient experience. +This Application layer consists of system and third-party applications. |main_project_name| applications will be able to use APIs to expose business logic as `abilities` that may be utilized inside other applications, thus allowing creation of more integrated experiences on the same device as well as distributed across devices.