Feature Analysis of OpenHarmony 3.1 Release - Introduction to OpenHarmony Hardware Resource Pooling Architecture

Author: Li Gang, OpenHarmony Distributed Hardware Management SIG Member, Distributed Hardware Expert, Huawei Technologies Co., Ltd.

As a distributed operating system for the all-scenario, all-connected, and all-intelligent era, OpenHarmony integrates the capabilities of various terminal devices, realizes hardware mutual assistance and resource sharing, and provides users with a smooth all-scenario experience. In this issue, we introduce OpenHarmony's hardware resource pooling framework to reveal how OpenHarmony achieves multi-device collaboration.

1. The evolution of hardware resource access

Access to hardware resources is the key to multi-device collaboration. Since the development of OpenHarmony, hardware resource access has experienced an evolution from "one-to-one" to "one-to-many".

1.1 One-to-one <br>In the initial stage of design, in order to solve the problem of collaboration between two devices, we integrated the hardware resources of the two devices through the distributed device virtualization platform provided by the system to realize "one-to-one". Hardware resource access.

$$ Figure 1 "One-to-One" Hardware Resource Access Model$$

The application accesses the device virtualization platform by integrating the multi-device virtualization Kit. The device virtualization platform provides data interaction between device A and device B and the virtualization capability of the device, so that the application of device A can access the hardware capability of device B and realize "one-to-one" hardware resource access. This access model can basically satisfy the resource access between two devices, but there are also certain constraints:

• The first point is that the application needs to integrate the multi-device virtualization Kit package to complete the access to hardware resources, which increases the development workload.
• The second point is that the access model restricts the application of device A to only access the hardware capabilities of device B at the same time, that is, it can only complete "one-to-one" hardware resource access.

1.2 One-to-many <br>With the continuous deepening of smart life in all scenarios, the "one-to-one" access method of device hardware resources can no longer meet the business needs of some complex scenarios. OpenHarmony continues to explore and innovate distributed technologies. By enhancing the original distributed device virtualization capabilities, it abstracts various hardware resources of multiple devices, such as screens, cameras, speakers, keyboards, sensors, and memory, to form The unified hardware resource pool in the "Super Virtual Terminal" supports on-demand allocation and recombination of hardware resources, and truly realizes the global call of hardware resources. Which distributed hardware capability the application needs to use, only needs to access the corresponding service, no need to integrate Kit; and the various hardware resources provided by the hardware resource pool can be accessed by different applications at the same time, realizing "one-to-many" Hardware resource access.

$$ Figure 2 "One-to-many" hardware resource access model$$

Based on "hardware resource pooling", developers can select and match appropriate capability modules in the hardware resource pool according to different business scenarios, and give full play to the capability advantages of different devices to build a new user experience.

2. Hardware resource pooling framework

Based on the innovative concept of "hardware resource pooling", OpenHarmony integrates hardware virtualization, hardware resource management and hardware data management capabilities, builds a hardware resource pooling framework, and provides a unified open interface for hardware capabilities, allowing developers to easily implement application development. As shown in Figure 3, the hardware resource pooling framework abstracts the hardware resources of various devices and provides various distributed services for northbound applications, such as distributed cameras, distributed screens, distributed audio, and distributed input. Provide unified device management and distributed hardware framework to manage hardware resources.

$$ Figure 3 Hardware Resource Pooling Framework$$

The following introduces the various components of the hardware resource pooling framework.

2.1 Device Manager
This component provides the authentication networking capability of account-independent distributed devices in the OpenHarmony system, and provides developers with a set of interfaces for distributed device discovery and authentication, as shown in Figure 4. Currently, the maximum number of devices that can be managed at the same time is 20 devices.

$$ Figure 4 Device Management Components$$

For details, please refer to the code repository of device management:
https://gitee.com/openharmony/device_manager

2.2 Distributed Hardware Framework (DistributedHardwareFwk)
This component provides information management capabilities for hardware resource pooling, and its main capabilities include access management, capability query, status management, authority management, and version management.
For details, please refer to the code repository of the distributed hardware framework: https://gitee.com/openharmony/distributed_hardware_fwk

2.3 Distributed Camera
This component provides the capability of cross-device camera access, abstracts the camera hardware capabilities of other terminal devices, and provides it to other devices as the camera capabilities in the hardware resource pool.
For details, please refer to the distributed camera code repository: https://gitee.com/openharmony/distributed_camera

2.4 Distributed Screen
This component provides cross-device screen capability calls, and provides the implementation of system screen projection, screen mirroring, and screen segmentation for the OpenHarmony system framework.
For details, please refer to the distributed screen code repository: https://gitee.com/openharmony/distributed_screen

3. Follow-up planning

In addition to distributed cameras and distributed screens, the hardware resource pooling framework will also provide distributed audio and distributed input capabilities in subsequent versions. Distributed Audio will provide hardware resource pooling capabilities for audio devices such as microphones, speakers, and earpieces, and provide application developers with audio services, enabling developers to freely select, switch, and combine audio devices to improve user experience. Distributed input will provide hardware resource pooling capabilities for input devices such as keyboards and mice, and enable application developers to call input capabilities across devices through input services to achieve multi-device collaboration.
The hardware resource pooling framework is still under construction, and we look forward to the vast number of developers joining us to witness the infinite possibilities of the Internet of Everything era!