HOME
  • GM-3568JHF
  • M4-R1
  • M5-R1
  • SC-3568HA
  • M-K1HSE
  • CF-NRS1
  • CF-CRA2
  • 1684XB-32T
  • 1684X-416T
  • C-3568BQ
  • C-3588LQ
  • GC-3568JBAF
  • C-K1BA
Shop
  • English
  • 简体中文
HOME
  • GM-3568JHF
  • M4-R1
  • M5-R1
  • SC-3568HA
  • M-K1HSE
  • CF-NRS1
  • CF-CRA2
  • 1684XB-32T
  • 1684X-416T
  • C-3568BQ
  • C-3588LQ
  • GC-3568JBAF
  • C-K1BA
Shop
  • English
  • 简体中文
  • SC-3568HA

    • Introduction

      • SC-3568HA Overview
    • Quick Start Guide

      • OpenHarmony Overview
      • Image Flashing
      • Setting Up the Development Environment
      • Hello World Application and Deployment
    • Application Development

      • ArkUI

        • Chapter 1 Introduction to ArkTS Language
        • Chapter 2 Introduction to UI Components and Practical Applications (Part 1)
        • Chapter 3 Introduction to UI Components and Practical Applications (Part 2)
        • Chapter 4 Introduction to UI Components and Practical Applications (Part 3)
      • Expand

        • Chapter 1 Getting Started Guide
        • Chapter 2 Referencing and Using Third-Party Libraries
        • Chapter 3: Application Compilation and Deployment
        • Chapter 4: Command-Line Factory Reset
        • Chapter 5: System Debugging -- HDC (Huawei Device Connector) Debugging
        • Chapter 6 APP Stability Testing
        • Chapter 7 Application Testing
    • Device Development

      • Chapter 1 Environment Setup
      • Chapter 2 Download Source Code
      • Chapter 3 Compiling Source Code
    • Peripheral And Iinterface

      • Raspberry Pi interface
      • GPIO Interface
      • I2C Interface
      • SPI communication
      • PWM (Pulse Width Modulation) control
      • Serial port communication
      • TF Card
      • Display Screen
      • Touch
      • Audio
      • RTC
      • Ethernet
      • M.2
      • MINI-PCIE
      • Camera
      • WIFI&BT
      • Raspberry Pi expansion board
    • Frequently Asked Questions

      • Resource Downloads
  • M-K1HSE

    • Introduction

      • M-K1HSE Introduction
    • Quick Start

      • Development environment construction
      • Source code acquisition
      • Compilation Notes
      • Burning Guide
    • Peripherals and interfaces

      • 01 Audio
      • 02 RS485
      • 03 Display
    • System customization development

      • System transplant
      • System customization
      • Driver Development
      • System Debugging
      • OTA Update

OpenHarmony Overview

1. Project Introduction

OpenHarmony is an open-source project incubated and operated by the OpenAtom Foundation. It aims to develop a framework and platform for intelligent terminal device operating systems based on open-source methodologies, targeting the era of all-scenario applications, fully connected ecosystems, and comprehensive intelligence. The initiative seeks to foster the flourishing development of the Internet of Everything (IoE) industry by promoting ubiquitous connectivity and intelligent integration across diverse devices and sectors.


1.1 Technical Architecture

OpenHarmony adopts a layered architectural design, progressing from bottom to top as follows: Kernel Layer, System Service Layer, Framework Layer, and Application Layer. The system functions are hierarchically structured in a "system > subsystem > component" decomposition model, enabling the pruning of non-essential components based on specific requirements in multi-device deployment scenarios. The technical architecture of OpenHarmony is illustrated below:

TOOL

1.1.1 Kernel Layer

  • Kernel Subsystem: Employs a multi-kernel design (Linux Kernel or LiteOS) to support the selection of appropriate OS kernels for different resource-constrained devices. The Kernel Abstract Layer (KAL) provides foundational kernel capabilities to upper layers by abstracting differences between multiple kernels, including process/thread management, memory management, file systems, network management, and peripheral device management.

  • Driver Subsystem: The Hardware Driver Framework (HDF) serves as the foundational infrastructure for open hardware ecosystems, providing unified peripheral access capabilities along with driver development and management frameworks.

1.1.2 System Service Layer

The System Service Layer represents the core capability aggregation of OpenHarmony, delivering services to applications through the Framework Layer. This layer comprises four key subsystem clusters:

a. Essential System Capability Subsystems: Provides foundational capabilities for distributed applications' operations, scheduling, and migration across multiple devices. This cluster includes:

  • Distributed SoftBus
  • Distributed Data Management
  • Distributed Task Scheduling
  • Common Foundation Libraries
  • Multi-modal Input
  • Graphics
  • Security
  • AI Subsystems

b. Basic Software Service Subsystems: Offers common and universal software services, including:

  • Event Notification
  • Telephony
  • Multimedia
  • DFX (Design For X) Subsystems

c. Enhanced Software Service Subsystems: Delivers device-specific differentiated capability-enhanced software services, composed of:

  • Smart Screen Dedicated Services
  • Wearable Dedicated Services
  • IoT Dedicated Services Subsystems

d. Hardware Service Subsystems: Provides hardware-related services, consisting of:

  • Location Services
  • User IAM (Identity and Access Management)
  • Wearable-specific Hardware Services
  • IoT-specific Hardware Services Subsystems

Notes

Depending on the deployment environments of different device forms, the Basic Software Service Subsystems, Enhanced Software Service Subsystems, and Hardware Service Subsystems can be tailored at the subsystem granularity level. Additionally, each individual subsystem can be further customized at the functional granularity level.

1.1.3 Framework Layer

The Framework Layer provides multi-language user program frameworks (C/C++/JS) and the Ability Framework, along with the ArkUI Framework applicable to JavaScript (JS) language, as well as multi-language framework APIs that expose various software and hardware services. The specific APIs supported by a device may vary according to the system's component-based tailoring configuration.

1.1.4 Application Layer

The Application Layer encompasses both system applications and third-party non-system applications. An application is composed of one or multiple FA (Feature Ability) or PA (Particle Ability) components. Specifically, FA components possess UI interfaces that enable user interaction capabilities, while PA components operate without UI interfaces, providing background task execution capabilities and unified data access abstractions. Applications developed based on FA/PA architecture can implement specific business functionalities, support cross-device scheduling and distribution, and deliver consistent and efficient user experiences.


1.2 Technical Features

1.2.1 Hardware Collaboration and Resource Sharing

a. Distributed Soft Bus:

  • The Distributed Soft Bus serves as a unified foundation for multi-device terminals, providing seamless interconnectivity through unified distributed communication capabilities. It enables rapid device discovery and connection while efficiently transmitting tasks and data.

b. Distributed Data Management:

  • Distributed Data Management is built upon the Distributed Soft Bus, enabling distributed management of both application and user data. User data is no longer tied to a single physical device, as business logic is decoupled from data storage. This architecture ensures seamless data continuity when applications run across devices, laying the foundational conditions for creating a consistent and fluid user experience.

c. Distributed Task Scheduling:

  • Distributed Task Scheduling leverages technical features such as the Distributed Soft Bus, Distributed Data Management, and Distributed Profile to establish a unified distributed service management mechanism (discovery, synchronization, registration, invocation). This mechanism supports cross-device operations including remote initiation, remote invocation, binding/unbinding, and migration. It dynamically selects the most optimal device to execute distributed tasks by considering factors such as device capabilities, location, operational status, resource utilization, as well as user habits and intentions.

d. Device Virtualization:

  • A Distributed Device Virtualization Platform enables resource integration, device management, and data processing across heterogeneous devices. By extending smartphone capabilities to peripheral devices, it creates a unified super virtual terminal through collaborative device interactions.

1.2.2 Develop Once, Deploy Anywhere

OpenHarmony provides the User Application Framework, Ability Framework, and UI Framework to ensure consistent application behavior across multiple devices during runtime. Develop Once, Deploy Anywhere.

The multi-device software platform maintains consistent APIs to ensure runtime compatibility of user applications across diverse terminals.

  • Supports real-time capability adaptation preview for diverse terminals (including CPU, memory, peripherals, and software resources) during the development lifecycle.

  • Supports dynamic scheduling of user presentation based on compatibility between user applications and the software platform.

1.2.3 Unified OS, Elastic Deployment

OpenHarmony leverages componentization and elastic component design methodologies to enable scalable hardware resource allocation, achieving on-demand deployment across diverse terminal devices. This architecture comprehensively supports various CPU architectures including ARM, RISC-V, and x86, while accommodating RAM configurations ranging from hundreds of KiB to GiB levels.


2. Download Address for System

OpenHarmony System Firmware Address: https://ci.openharmony.cn/workbench/cicd/dailybuild/dailylist Download dayu200 Firmware

Reference:

For detailed information, please refer to: https://docs.openharmony.cn/pages/v5.0/en/OpenHarmony-Overview.md


Edit this page on GitHub
Last Updated:
Contributors: zsl, zwhuang
Next
Image Flashing