Expanding the Ecosystem Through Distributed Soft Bus


openEuler aims to build an operating system for digital infrastructure. To promote cooperation with the OpenHarmony ecosystem and implement interoperability in device-edge scenarios, openEuler introduces the distributed soft bus (DSoftBus) technology to the embedded field.

DSoftBus is an open source communication base for distributed devices developed by the OpenHarmony community. It enables unified distributed communication between devices, achieving imperceptible device discovery and efficient data transmission. OpenHarmony is designed for smart devices, IoT devices, and industrial devices that require strong interaction, while openEuler is oriented to servers, edge computing, cloud, and embedded devices that require high reliability and performance. DSoftBus is an example of the collaborative technologies that allow users from both communities to explore more industry applications.

For details about the working principles and processes of DSoftBus, see openEuler Distributed Soft Bus.



Device NameOSDescription
Raspberry Pi 4BopenEuler22.03-LTS-SP1Raspberry Pi with openEuler installed
DAYU200 rk3568 development boardopenHarmony 3.1 ReleaseDevelopment board with OpenHarmony installed


ItemDownload URLDescription
openEuler22.03-LTS-SP1https://www.openeuler.org/zh/download/Download the openEuler image in the raspi_img directory. For details, see Installing openEuler on Raspberry Pi.
openHarmony 3.1 Releasehttps://gitee.com/openharmony/manifest.gitDownload the OpenHarmony OS. For details, see Standard System Overview.
HUAWEI DevEco Studiohttps://developer.harmonyos.com/cn/develop/deveco-studio#downloadIntegrated development environment for OpenHarmony. For details, see DevEco Studio User Guide (OpenHarmony). The code in this document is based on OpenHarmony SDK 9.

Obtaining Code

This document uses a Raspberry Pi (openEuler) and an RK3568 development board (openHarmony) for ecosystem interconnection demonstration.

Obtain the code for openEuler (Raspberry Pi):

# Operations on openEuler are performed on Raspberry Pi.

# The server software package has been integrated into openEuler22.03 LTS SP1. Run the following command to install the server software package:

dnf install dsoftbus -y

# For the client code, use softbus_client_main.c provided by the openEuler Embedded SIG (https://openeuler.gitee.io/yocto-meta-openeuler/master/features/distributed_softbus.html).

Obtain the code for OpenHarmony (RK3568 development board):

# Operations on OpenHarmony (RK3568 development board) are performed on Windows.

# DSoftBus has been integrated into the openHarmony 3.1 Release image. You do not need to manually obtain the server code.

# The client code is based on Native C++. You can run the following git command to download the reference code.

git clone https://gitee.com/liheavy/softbus_client_app.git

Compiling Code

Compile the code for openEuler (Raspberry Pi):

# After installing DSoftBus, save softbus_client_main.c to any path and run the following gcc command to compile the file. After the compilation is complete, the executable file softbus_client_main is generated in the path. Add the execute permission to the file.

gcc softbus_client_main.c -I/usr/include/dsoftbus/ -L /usr/lib64 -lsoftbus_client.z -lboundscheck -o softbus_client_main

chmod u+x softbus_client_main

Compile the code for OpenHarmony (RK3568 development board):

  • Configure the IDE by referring to the HUAWEI DevEco Studio User Guide.

  • Open the downloaded softbus_client_app/softbus_client_sample reference code using DevEco. DevEco automatically initializes the project based on the configuration file.

    After the initialization, generate a signature file: File --> Project Structure --> Project --> Signing Configs --> Automatically generate signature.


  • OpenHarmony SDK 9 does not provide the API of DSoftBus. Therefore, this project directly uses the API of DSoftBus service in the application. The dependent .so files (libsoftbus_client.z.so and libsec_shared.z.so) are required. Copy the file to the dynamic library path of the local openHarmony SDK. The .so files are downloaded to the local PC (required_so folder) together with the source code. You can also use the hdc tool to copy the two .so files in RK3568. The .so file path is /lib/xxx.so.

    To view the local OpenHarmony SDK installation path: File --> Settings --> OpenHarmony SDK.


    Copy libsoftbus_client.z.so and libsec_shared.z.so to OpenHarmony_SDK_installation_path/native/x.x.x.x/sysroot/usr/lib/arm-linux-ohos/.

    After the compilation is complete, compile the code in DevEco: Build --> Build Hap(s)/App(s) --> Build Hap(s).


Running Code


Configuring Device ID

Configure device ID on openEuler (Raspberry Pi)

The dependency on the device management module is temporarily removed in the current version of DSoftBus. To simplify device ID obtaining, the device ID is read from the /etc/SN file. Therefore, you need to write the device ID to /etc/SN before starting DSoftBus. Each device must have a unique ID to avoid authentication and communication errors.

# Assume the device ID is 1.
echo "1" >>/etc/SN

Connecting to the Network

The two devices must be in the same LAN and reachable to each other. You can run the ifconfig command on the OSs of each device to view the IP addresses.

On openEuler (Raspberry Pi):

  • Start the DSoftBus service.

    # DSoftBus provides the softbus_server_main command. Execute the command directly.

On OpenHarmony (RK3568 development board):

  • Connect to the RK3568 development board from the local PC.

    Connect the USB port of the local PC and the OTG USB port of the RK3568 development board. If the development board is displayed in the device list in the upper right corner of DevEco, The device is connected.


  • Modify the permission configuration file of DSoftBus.

    OpenHarmony DSoftBus restricts access to its functions based on application permissions. Therefore, you need to modify the DSoftBus configuration file to run the demo.

    # The permission configuration file can be replaced by the hdc_std tool, which is installed with OpenHarmony SDK. The installation path is:
    # The DSoftBus permission configuration file on RK3568 is in read-only mode. Run the following command to change the file system to read-write mode:
    hdc_std.exe shell "mount -o remount,rw /"
    # Replace the softbus_trans_permission.json file on RK3568 with the one from the softbus_client_app repository:
    hdc_std.exe file send softbus_trans_permission.json /system/etc/communication/softbus/
  • Restart the DSoftBus service.

    # Run the following command to restart the DSoftBus service for the modified permission configuration file to take effect:
    ps -ef | grep softbus_server | grep -v grep
    kill -9 PID_queried_in_the_last_step

Device Authentication

The OpenHarmony and openEuler devices need to be added as trusted devices for each other during networking. Therefore, before the two devices communicate with each other, they need to be authenticated through the Hichain module. For details, see Adding Trusted Devices. The following operations are performed on Raspberry Pi.

  • Create a soft link of the dynamic library.

    # This method requires libsec_shared.z.so, which is replaced with libboundscheck.so in openEuler DSoftBus. Therefore, you need to create a soft link to use libsec_shared.z.so.
    ln -s /usr/lib64/libboundscheck.so /usr/lib64/libsec_shared.z.so
    # In the Arm environment, /lib64/1d-linux-aarch64.so.1 is also required.
    ln -s /lib/ld-linux-aarch64.so.1 /lib64/ld-linux-aarch64.so.1
  • Run the authentication client.

    # The demo executable file (devicemanager) of the authentication client is also stored in the hichain_sample directory of the softbus_client_app repository.
    chmod u+x devicemanager

    Enter l as prompted to list the devices in the same LAN.


    Enter the OpenHarmony device number as prompted for authentication. After the number is entered, a confirmation dialog box is displayed on the RK3568 development board, asking whether to allow the peer device to connect. Click Allow and enter l on the Raspberry Pi. The device status changes from discovery to online, indicating a successful authentication.


Device Communication

  • Burn and run the client on OpenHarmony (RK3568 development board).

    Connect the local PC to the RK3568 development board and click Run in the upper part of DevEco.


    After the burning is complete, RK3568 directly runs the app.


  • Send data from openEuler (Raspberry Pi).

    # Run the compiled softbus_client_main executable file.

    The networking devices are displayed.


    Enter c as prompted.


    Enter the ID of the openHarmony device as prompted.


​ The received character string is displayed on the top of the RK3568 development board screen.

  • View terminal information OpenHarmony (RK3568 development board).

    Click the refresh icon on the app page. The devices connected to the device are displayed. Click the device icon to display the basic information about the device.

  • Send data from OpenHarmony (RK3568 development board):

    Click Send Data on the app page to send data to OpenEuler.

​ The received information is displayed on OpenEuler (Raspberry Pi).


​ The demonstration of interconnection between openEuler and OpenHarmony through DSoftBus is complete.

6. Summary

This document demonstrates how OpenHarmony devices and openEuler devices communicate with each other through the DSoftBus. The server code is being continuously optimized to support more distributed scenarios. The client code is only a demo and needs to be optimized. For example, the standard method for invoking DSoftBus in an OpenHarmony app is to develop a system ability to call the DSoftBus API and integrate the system ability to the SDK. However, in this document, the app directly invokes the DSoftBus API. We welcome enthusiasts to participate in the development to enrich the embedded capabilities of openEuler.

Bug Catching

Buggy Content

Bug Description

Submit As Issue

It's a little complicated....

I'd like to ask someone.


Just a small problem.

I can fix it online!

Bug Type
Specifications and Common Mistakes

● Misspellings or punctuation mistakes;

● Incorrect links, empty cells, or wrong formats;

● Chinese characters in English context;

● Minor inconsistencies between the UI and descriptions;

● Low writing fluency that does not affect understanding;

● Incorrect version numbers, including software package names and version numbers on the UI.


● Incorrect or missing key steps;

● Missing prerequisites or precautions;

● Ambiguous figures, tables, or texts;

● Unclear logic, such as missing classifications, items, and steps.


● Technical principles, function descriptions, or specifications inconsistent with those of the software;

● Incorrect schematic or architecture diagrams;

● Incorrect commands or command parameters;

● Incorrect code;

● Commands inconsistent with the functions;

● Wrong screenshots.

Risk Warnings

● Lack of risk warnings for operations that may damage the system or important data.

Content Compliance

● Contents that may violate applicable laws and regulations or geo-cultural context-sensitive words and expressions;

● Copyright infringement.

How satisfied are you with this document

Not satisfied at all
Very satisfied
Click to create an issue. An issue template will be automatically generated based on your feedback.