Heterogeneous cloud edge-end test field computing scheduling method and system based on risc-v architecture

Abstract

The application provides a heterogeneous cloud edge-end test field computing scheduling method based on a RISC-V architecture, a cloud native cluster is constructed, and the cloud native cluster comprises a cloud node, an edge computing node, an edge service node and an Internet of Things terminal node; wherein at least part of the edge computing node and / or the edge service node is a RISC-V instruction set architecture; the edge computing node and the edge service node are divided into roles; a lightweight index monitoring device for collecting running index data is deployed on each node of the cloud native cluster; a Web integrated development environment is deployed in the cloud native cluster to provide an integrated development process; and a scheduler performs task scheduling decisions based on the divided node roles, the instruction set architecture, the running index data and a business topology dependency relationship. In this way, the application can manage heterogeneous nodes in a unified manner, automatically schedule cross-architecture tasks, observe running states in real time, and complete a complete process from development to deployment on the same platform.

Description

Technical Field

[0001] This invention relates to the field of cloud computing technology, and in particular to a heterogeneous cloud-edge-device test field computing scheduling system and method based on RISC-V architecture. Background Technology

[0002] Current cloud-native systems are designed around cloud data centers, and their scheduling logic, resource models, toolchain ecosystems, and monitoring methods are all based on the premise of homogeneous nodes, stable networks, and similar computing capabilities. Container platforms built on this premise can achieve high efficiency in cloud environments. However, as application scenarios gradually extend to the edge and terminal devices, the structural defects within traditional cloud-native systems are becoming apparent, and these defects become increasingly pronounced with the increasing heterogeneity of nodes.

[0003] In a cloud-edge-device environment, the physical location, network environment, power conditions, hardware performance, and instruction set architecture of computing nodes are highly discrete. Cloud data center nodes have stable power supply and network environments, while edge computing nodes are typically deployed at the network edge with bandwidth limitations and latency fluctuations. Terminal devices may be subjected to uncertain conditions such as high temperatures, movement, and intermittent power supply. Traditional cloud-native systems' node abstraction methods cannot accurately represent these cross-layer, cross-architecture, and cross-location differences, thus limiting deployment behavior. For example, users may want to run global control logic long-term in the cloud, perform inference tasks on edge computing nodes, and run lightweight data collection programs on terminal devices. However, the system lacks the technical means to express these deployment topologies, often relying on manually writing numerous tags or scripts to achieve this, and even then, consistency cannot be guaranteed as the scale increases.

[0004] The shortcomings of resource scheduling logic are more pronounced in heterogeneous environments. Traditional schedulers make decisions based on the basic resources of CPU and memory. However, in a cloud-edge-device architecture, factors such as CPU frequency, the number of available cores, network bandwidth limitations, differences in memory access latency, and cache structure all significantly impact task execution efficiency. The system lacks quantitative modeling and comprehensive judgment of these hardware characteristics, often resulting in high-performance nodes being over-concentrated in usage while low-performance nodes remain idle for extended periods. This situation is more likely to lead to performance imbalances in multi-instruction set architectures. Furthermore, existing systems cannot fundamentally verify the effectiveness of multi-tenant isolation. Although container runtimes provide basic isolation mechanisms, the system lacks the ability to continuously verify this using underlying metrics. It cannot determine whether the CPU contention among different container carriers is reasonable when high-load tasks increase, making it difficult to guarantee system reliability and predictability.

[0005] While cloud-native toolchains are highly mature in cloud environments, they face challenges in application across the cloud-edge-device scope. For example, developers need to build applications for various hardware architectures, including x86, ARM64, and RISC-V. Traditional IDEs (Integrated Development Environments) and remote debugging tools often cannot handle cross-architecture builds, dependency differences, and distribution requirements under unstable networks. Images generated during development require multiple versions for different architectures, and build tasks may need to be tested on terminal devices. However, the performance of terminal devices differs significantly from that of the cloud, resulting in a lack of a unified debugging mechanism. Consequently, development toolchains struggle to handle unified build, testing, and deployment tasks across layers and architectures.

[0006] The monitoring system also fails to meet the actual needs of the cloud-edge-device architecture. Traditional monitoring platforms mainly focus on observing the status of nodes in the cloud center, relying on high-bandwidth networks to transmit a large number of metrics. However, the network bandwidth of edge and terminal devices is limited, lacking the ability to perform high-frequency sampling and large-scale metric reporting. Furthermore, the monitoring items lack the ability to correlate and analyze factors such as computing node topology, physical location, network characteristics, energy status, and real-time performance, making it difficult to determine the root cause of problems when facing complex latency paths, local congestion, and highly heterogeneous node failures. In particular, differences in CPU performance, competition, and network changes in hybrid architecture systems are even more difficult to capture using traditional monitoring systems.

[0007] In summary, traditional cloud-native systems fail to provide sufficient resource expression capabilities, scheduling and inference capabilities, heterogeneous software construction capabilities, and multi-source metric collection capabilities when facing cloud-edge-device collaborative computing scenarios. This makes it difficult for the system to complete topology deployment according to actual business needs, and it also fails to achieve optimal performance and controllable operation in multi-architecture, multi-level, and multi-tenant environments. These structural problems become increasingly prominent in the context of intelligent and real-time applications relying more and more on edge and terminal nodes, requiring a technical solution that restructures at the architectural level to address these inadequacies in adaptability. Summary of the Invention

[0008] To address the problems existing in the prior art, this invention proposes a computation scheduling method and system for a heterogeneous cloud-edge-device test field based on the RISC-V architecture, which supports unified development, unified scheduling, and unified operation and maintenance of applications in a heterogeneous cloud-edge-device environment.

[0009] To achieve the aforementioned technical effects, on the one hand, this invention provides a computation scheduling method for a heterogeneous cloud-edge-device test field based on a RISC-V architecture, comprising the following steps:

[0010] Construct a cloud-native cluster, which includes cloud nodes, edge computing nodes, edge service nodes, and IoT terminal nodes; wherein at least some of the edge computing nodes and / or the edge service nodes are based on the RISC-V instruction set architecture.

[0011] The edge computing nodes and the edge service nodes are assigned roles to form an operational structure that separates computing and services; wherein, in the operational structure, computing-intensive tasks are assigned to the edge computing nodes, and service-responsive tasks are deployed on the edge service nodes;

[0012] A lightweight metric monitoring device is deployed on each node of the cloud-native cluster. The lightweight metric monitoring device is used to collect operational metric data locally on the node.

[0013] A web integrated development environment supporting cross-build and remote debugging of multiple instruction sets is deployed within the cloud-native cluster. The web integrated development environment is used to provide an integrated development process from code writing to deployment and verification.

[0014] The scheduler makes task scheduling decisions based on the partitioned node roles, instruction set architecture, the aforementioned operational metric data, and business topology dependencies.

[0015] Furthermore, the operational metrics data include at least one of the following: CPU utilization, memory usage, network bandwidth, and network latency.

[0016] Furthermore, the Web integrated development environment supports cross-compilation, image building, and remote debugging for multiple instruction set architectures such as x86, ARM64, and RISC-V, and provides the function of one-click triggering deployment and rollback on different level nodes.

[0017] Furthermore, the lightweight indicator monitoring device reports the collected operational indicator data to the control plane in a compressed or aggregated manner.

[0018] On the other hand, this invention also provides a heterogeneous cloud-edge-device testbed computing scheduling system based on RISC-V architecture, including a control plane, a data plane, and a development plane; wherein:

[0019] The control plane, deployed on the cloud side, is used to maintain cluster status and metadata, and to execute task scheduling decisions based on node roles, instruction set architecture, operational metric data, and business topology dependencies.

[0020] The data plane, which is communicatively connected to the control plane, includes cloud nodes, edge computing nodes, edge service nodes, and IoT terminal nodes. At least some of the edge computing nodes and / or the edge service nodes are based on the RISC-V instruction set architecture, and the edge computing nodes and edge service nodes form a computing and service separation operation structure. Each node of the data plane is equipped with a lightweight indicator monitoring device for collecting operational indicator data locally and reporting it to the control plane.

[0021] The development plane, deployed within the system, is a web-based integrated development environment that supports cross-construction of multiple instruction sets and remote debugging, providing an integrated development process from code writing to deployment and verification.

[0022] Furthermore, the nodes in the data plane are configured with a registration interface for reporting processor architecture, capabilities, roles, and levels, and the control plane is configured with a manager for marking RISC-V node architecture characteristics based on the reported information.

[0023] Furthermore, the edge computing nodes are used to carry out computationally intensive tasks, and the edge service nodes are used to carry out service response tasks.

[0024] Furthermore, the operational metrics data include at least one of the following: CPU utilization, memory usage, network bandwidth, and network latency.

[0025] Furthermore, the lightweight indicator monitoring device is equipped with a data compression or aggregation unit for processing the operational indicator data to be reported.

[0026] Furthermore, the development plane supports cross-compilation, image building, and remote debugging for multiple instruction set architectures such as x86, ARM64, and RISC-V, and provides the function of one-click triggering deployment and rollback on different level nodes.

[0027] Compared to cloud-native systems designed for collaborative scenarios involving cloud computing, edge computing, and the Internet of Things, the heterogeneous cloud-edge-device testbed computing scheduling method and system based on RISC-V architecture provided in this invention have the following advantages:

[0028] (1) Under the premise of introducing RISC-V instruction set architecture nodes, realize the unified management and scheduling of heterogeneous resources of cloud, edge and terminal in the same cloud-native cluster, and form a "computing and service separation" operation structure on the edge side;

[0029] (2) Build an indicator monitoring mechanism that can be linked with the scheduling strategy in the cloud-edge-terminal heterogeneous environment so that edge and terminal nodes can still provide measurement data that can be used for scheduling decision and performance verification under network-limited and resource-limited conditions;

[0030] (3) Deploy a Web Integrated Development Environment (WebIDE) adapted to a multi-instruction set architecture within a cloud-native cluster to connect the full-stack development and operation process from code writing, cross-compilation, image building, deployment and release to operation verification, and realize an integrated development experience and automated delivery capability in multi-architecture and multi-level environments;

[0031] (4) Under the conditions of cloud-edge-device hybrid topology and multi-level resource constraints, design a scheduling strategy for cloud-native scenarios so that the scheduling decision can simultaneously consider node level location, network latency, bandwidth limitation, hardware heterogeneity and business topology dependency, thereby ensuring the performance and stability of the overall system. Attached Figure Description

[0032] Figure 1 A flowchart illustrating the steps of the heterogeneous cloud-edge-device test field computation scheduling method based on RISC-V architecture provided in an embodiment of the present invention;

[0033] Figure 2 A schematic diagram of the hardware cluster architecture of a cloud-edge-device experimental bed system for the heterogeneous cloud-edge-device experimental field computing scheduling method based on RISC-V architecture provided in an embodiment of the present invention.

[0034] Figure 3 A schematic diagram of the software architecture of a heterogeneous edge-cloud experimental bed system for the computational scheduling method of the heterogeneous cloud-edge-device experimental field based on RISC-V architecture provided in an embodiment of the present invention;

[0035] Figure 4 A flowchart illustrating the cloud-edge-device experimental task deployment and horizontal scaling of the heterogeneous cloud-edge-device test field computing scheduling method based on RISC-V architecture, provided as an embodiment of the present invention.

[0036] Figure 5 This is a schematic diagram of the heterogeneous cloud-edge-device test field computing scheduling method based on RISC-V architecture provided in an embodiment of the present invention in a smart home cloud-edge-device application scenario.

[0037] Figure 6 A schematic diagram of the heterogeneous cloud-edge-device test field computing scheduling method based on RISC-V architecture provided in an embodiment of the present invention in a scenario where a drone swarm is controlled by a service node;

[0038] Figure 7 This is a schematic diagram of the heterogeneous cloud-edge-device test field computing scheduling system based on the RISC-V architecture, provided as another embodiment of the present invention. Detailed Implementation

[0039] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0040] It should be noted that references to "an embodiment," "embodiment," "example embodiment," etc., in this specification refer to the described embodiment including specific features, structures, or characteristics, but not every embodiment must include these specific features, structures, or characteristics. Furthermore, such expressions do not refer to the same embodiment. Moreover, when describing specific features, structures, or characteristics in conjunction with embodiments, whether or not explicitly described, it is indicated that incorporating such features, structures, or characteristics into other embodiments is within the knowledge of those skilled in the art.

[0041] Furthermore, certain terms are used in the specification and subsequent claims to refer to specific components or parts. Those skilled in the art will understand that manufacturers may use different names or terms to refer to the same component or part. This specification and subsequent claims do not distinguish components or parts by differences in name, but rather by differences in function. The terms "comprising" and "including" used throughout the specification and subsequent claims are open-ended and should be interpreted as "including but not limited to." Additionally, the term "connection" here includes any direct and indirect electrical connection means. Indirect electrical connection means include connections made through other means.

[0042] In building a cloud-edge-device collaborative system, it was discovered that traditional cloud-native architectures, due to their assumptions of homogeneous nodes, stable networks, and unified instruction sets, struggle to support the real-world demands of edge computing environments. To enable heterogeneous resources to collaboratively run in a cloud-native manner on the same platform, this invention first introduces a multi-instruction set architecture, specifically incorporating RISC-V as a crucial component of edge nodes. This empowers the cluster to handle high-efficiency, low-power devices, overcoming the limitations of traditional platforms that only support x86 and ARM64. Building upon this, the invention further recognizes the resource contention issues exhibited by edge nodes when undertaking inference computing and real-time services. Through multiple rounds of experiments, it was confirmed that only by establishing a structural separation between computing and services at the edge can the system achieve predictable latency and stability. Therefore, this invention introduces a runtime model within the cluster capable of distinguishing between the two types of tasks, enabling edge nodes to play different roles and form a coordinated relationship.

[0043] This invention encountered challenges related to monitoring blind spots and unobservable scheduling during long-term testing. Due to the large network fluctuations and limited bandwidth of edge devices, traditional cloud-based monitoring systems cannot promptly reflect key operational indicators such as CPU contention status, link quality, and power consumption characteristics of edge nodes. Therefore, this invention further introduces a lightweight indicator acquisition device into the cluster, enabling it to directly acquire underlying metric data locally on the device and participate in scheduling decisions, thereby compensating for the structural deficiencies of the original cloud-native monitoring system in edge environments. To enable applications in multi-instruction set environments to complete coding, building, testing, deployment, and verification within the same cluster, this invention deploys an online IDE (Integrated Development Environment) within the cluster, eliminating the need for the development environment to rely on external toolchains and frequently switching development paths between different architectures. By directly incorporating the development process into the cluster control scope, this invention allows code writing, cross-compilation, image building, and runtime debugging to be completed within the same infrastructure, thus forming a unified development pipeline capable of covering multiple architecture devices and different node levels.

[0044] After comprehensively analyzing the differences in the operational characteristics of the cloud, edge, and terminal, this invention proposes an architecture that integrates cloud-native technology, RISC-V architecture, edge computing and service separation mechanism, lightweight monitoring capabilities, and a full-stack development environment into a single cluster. This enables the entire system to manage heterogeneous nodes in a unified manner, automatically schedule cross-architecture tasks, observe operational status in real time, and complete the entire process from development to deployment on the same platform, thereby forming a full-stack integrated infrastructure for cloud-edge-terminal scenarios.

[0045] To enable those skilled in the art to reproduce and implement the present invention, the following detailed description, in conjunction with the accompanying drawings and specific embodiments, will illustrate the RISC-V-based heterogeneous cloud-edge-device testbed computing scheduling method and system. These embodiments are specific illustrations of the present invention and are helpful in understanding the invention, but should not be construed as limiting the invention.

[0046] Figure 1 This invention illustrates a computation scheduling method for a heterogeneous cloud-edge-device test field based on a RISC-V architecture, comprising the following steps:

[0047] S101: Construct a cloud-native cluster, which includes cloud nodes, edge computing nodes, edge service nodes, and IoT terminal nodes; wherein at least some of the edge computing nodes and / or edge service nodes are based on the RISC-V instruction set architecture. In other words, this embodiment constructs a unified cloud-native cluster, bringing heterogeneous nodes located at different physical layers (cloud, edge, and terminal) into the same management domain; and introduces the RISC-V instruction set architecture to the edge side as computing or service nodes, thereby breaking through the limitations of traditional cloud-native platforms that primarily target x86 / ARM homogeneous resources, and providing the entire system with the ability to process diverse, low-power edge devices.

[0048] By managing multi-level and multi-architecture nodes through a single cloud-native cluster, the tedious work of building separate clusters and toolchains for different architectures can be avoided, reducing deployment and operation and maintenance costs, and enabling applications to flexibly migrate and expand between the cloud, edge, and terminal according to business needs.

[0049] S102: Roles are defined for edge computing nodes and edge service nodes, forming an operational structure that separates computing from services. Within this structure, computationally intensive tasks are assigned to edge computing nodes, while service-responsive tasks are deployed on edge service nodes. By dividing edge nodes into those focused on computation and those focused on providing external services, and clearly defining their task orientation (computationally intensive tasks such as AI inference and batch processing flow to computing nodes; service-responsive tasks such as API interfaces and real-time control flow to service nodes), decoupling of computation and services is achieved.

[0050] Existing cloud-native platforms cannot simultaneously manage nodes with multiple instruction set architectures such as x86, ARM64, and RISC-V within the same cluster, nor can they architecturally differentiate edge computing nodes handling large-scale computing loads from edge service nodes serving user interactions or local services for edge scenarios. Traditional approaches rely on manual labeling and script constraints, which are neither sufficient to express business needs for deployment topology nor maintain consistency during scaling. See also Figure 2 In specific implementation, this embodiment introduces a RISC-V node awareness and constraint mechanism into the cloud-native framework, and divides edge nodes into different roles, primarily for computing (Edge-c) and primarily for service (Edge-s). This enables the scheduler to match appropriate instruction set architectures when allocating tasks, and to distribute compute-intensive tasks and service-responsive tasks across different edge nodes, thereby maintaining service latency stability while ensuring computing performance.

[0051] This invention introduces RISC-V nodes at the edge and distinguishes between compute and service nodes. While ensuring stable service response latency, it improves the edge's capacity to handle computationally intensive tasks such as inference and batch processing. This transforms edge nodes from single-function roles into collaborative compute and service combinations, thereby enhancing the flexibility and reliability of the overall cloud-edge-device computing power structure. Through localized metric monitoring and linkage with scheduling strategies, this invention enables scheduling decisions to be made based on near real-time operational status. This improves multi-tenant CPU isolation and network resource utilization, provides a clearer observation channel for identifying performance bottlenecks and abnormal behavior, and reduces operational risks.

[0052] S103: Deploy lightweight metric monitoring devices on each node of the cloud-native cluster. These devices are used to collect operational metric data locally on the nodes. Specifically, the operational metric data includes at least one of the following: CPU utilization, memory usage, network bandwidth, and network latency.

[0053] See Figure 3 The software architecture shown in this embodiment, in addition to building a cloud-native architecture and introducing multiple runtimes at the cloud, edge, and terminal levels, also focuses on the difficulty of traditional cloud-side monitoring systems obtaining sufficiently granular and scheduling-related operational metrics in cloud-edge-terminal collaborative scenarios. Edge and terminal nodes often operate in environments with limited bandwidth and unstable networks, making it impossible to upload large amounts of monitoring data at high frequencies. Furthermore, existing monitoring systems rarely directly utilize low-level metrics such as CPU usage time statistics, queue latency, and link quality to provide decision-making basis for scheduling strategies. Therefore, this embodiment preferably deploys the Prometheus monitoring platform on cluster nodes, introducing lightweight metric monitoring devices or agents at edge and terminal nodes. Key metrics such as CPU utilization, latency, and bandwidth utilization are collected locally and reported to the control plane in a compressed or aggregated manner. This data is then linked with customized scheduling strategies, allowing the scheduler to make judgments based on real-time performance status when selecting nodes, thereby improving multi-tenant isolation and overall resource utilization.

[0054] S104: Deploy a Web integrated development environment (IDE) within a cloud-native cluster that supports cross-compilation of multiple instruction sets and remote debugging. This IDE provides an integrated development process from code writing to deployment and verification. The IDE in this embodiment supports cross-compilation, image building, and remote debugging for multiple instruction set architectures, including x86, ARM64, and RISC-V, and provides one-click deployment and rollback functionality across different node levels.

[0055] This addresses the technical challenge of fragmented application development workflows in multi-instruction set architecture environments. In traditional development models, developers typically need to perform cross-compilation, container image building, and deployment testing on different hardware architectures such as x86, ARM64, and RISC-V, either locally or in multiple independent development environments. This model not only requires configuring and maintaining multiple complex toolchains, but its build and testing environments are also difficult to maintain in line with the actual heterogeneous cluster environment where the application will ultimately run, leading to extended debugging cycles and significantly increased operational costs.

[0056] To address the aforementioned issues, this embodiment deploys a Web Integrated Development Environment (WebIDE) within the cloud-native cluster that supports cross-builds of multiple instruction sets and remote debugging. This environment integrates source code management, dependency management, build scripts, image repositories, and deployment pipelines into the cluster management system, forming an embedded development plane.

[0057] Specifically, developers can access this web-based integrated development environment (IDE) through a browser to perform coding, dependency management, and build configuration in an environment consistent with the production cluster. See also Figure 4 This environment provides cross-compilation toolchains for multiple instruction set architectures such as x86, ARM64, and RISC-V, supporting application building and container image generation for different architectures. Furthermore, developers can use the unified interface provided by this environment to trigger deployment, testing, and rollback operations of applications on different levels of nodes (cloud nodes, edge computing nodes, edge service nodes, or IoT terminal nodes) with a single command. Through the above methods, this embodiment achieves a seamless end-to-end workflow from code writing, cross-compilation, image building, deployment testing to production release within a unified cloud-native cluster, effectively simplifying the application development, integration, and experimentation process for heterogeneous cloud-edge-device scenarios.

[0058] By deploying a web-based integrated development environment (IDE) within a cluster and streamlining source code management, cross-compilation, image building, and deployment pipelines, this invention converges the development and delivery processes, previously scattered across multiple environments, onto a single platform. This enables applications targeting multi-architecture, multi-level scenarios to complete the entire development-to-deployment process within a single cluster, significantly shortening the development cycle and improving version consistency and release quality. Overall, this embodiment simultaneously achieves unified management of heterogeneous resources, edge architecture optimization, collaborative scheduling and monitoring, and a full-stack development loop on the same cloud-native platform, enhancing performance, stability, observability, and maintainability in the cloud-edge-device collaborative environment at the system level.

[0059] S105: The scheduler makes task scheduling decisions based on the partitioned node roles, instruction set architecture, operational metric data, and business topology dependencies. Through this multi-factor joint optimization scheduling strategy, the system can automatically achieve the optimal balance between performance, latency, stability, and resource utilization under cloud-edge-device hybrid topology and resource constraints.

[0060] This invention provides a full-stack, integrated cloud-edge-device collaborative computing platform. Within a single cloud-native cluster, this platform uniformly manages cloud nodes, edge computing nodes, edge service nodes, and IoT terminal nodes, as shown in Table 1 below, forming a multi-level heterogeneous resource pool.

[0061] Table 1:

[0062]

[0063] The platform's core architecture integrates the following features: it introduces support for multi-instruction set architectures, including RISC-V, and achieves separation of computing and services at the edge. At the same time, it deploys indicator monitoring devices and a Web integrated development environment within the system, building a full-stack integrated system that runs through development, deployment, scheduling, and operation monitoring. This systematically alleviates and optimizes the problems faced by traditional cloud-native systems in cloud-edge-device collaborative scenarios, such as insufficient adaptability, uneven resource utilization, lack of scheduling basis, and fragmented development links.

[0064] Based on the above architecture, the system provided in this embodiment achieves unified abstraction and scheduling of multi-level, multi-architecture resources. This allows applications to be flexibly distributed among cloud nodes, edge computing nodes, edge service nodes, and terminal nodes according to business needs, thereby improving resource utilization efficiency and system scalability.

[0065] In practical implementation, the heterogeneous cloud-edge-device testbed computing scheduling method based on RISC-V architecture described in this embodiment is implemented by deploying the platform on cloud-native infrastructure using container technology. The entire platform consists of three parts: a control plane, a data plane, and a development plane. The control plane typically runs in the cloud-side data center and is responsible for core functions such as cluster status maintenance, scheduling policy execution, monitoring data aggregation, and development pipeline orchestration. The data plane consists of cloud nodes, edge computing nodes, edge service nodes, and IoT terminal nodes that actually carry the business. These nodes can be located in different physical locations and access the same cluster through a dedicated network or a secure public network channel. The development plane relies on the Web integrated development environment deployed within the cluster, using a browser as the entry point, to provide developers with a unified interface for coding, building, debugging, and deployment.

[0066] Furthermore, the platform is deployed and runs in two typical cloud-edge-device collaborative scenarios. Figure 5For smart home scenarios, various terminal devices in the living room, such as lights, air purifiers, and humidifiers, are connected to the public network through an IoT development platform. The cloud platform uniformly manages device access and policy distribution. Control nodes and service nodes are deployed at the edge. The control nodes are responsible for executing local control logic and status aggregation, while the service nodes provide a unified home control service interface to the outside world, realizing the coordination of cloud policies, edge control, and terminal execution. Figure 6 In the drone swarm scenario, multiple small drones establish a connection with the platform through a service node. The service node uses a publish / subscribe mechanism to broadcast task instructions to the drones in the swarm and receive status feedback. The cloud-side or edge control logic uniformly plans the formation flight and task execution, thereby verifying the cloud-edge-device collaborative control capability of the platform under the conditions of multiple terminals, multiple protocols, and multiple tasks.

[0067] All nodes participating in the cluster must complete a registration process upon joining the platform. During registration, nodes report their basic attribute information to the control plane, including processor architecture type, CPU clock speed, number of physical cores and logical cores, available memory capacity, local storage capacity and read / write bandwidth, network bandwidth limit and typical latency range, etc. They also report their expected role and hierarchical level. Based on this information, the platform labels nodes as cloud nodes, edge computing nodes, edge service nodes, or IoT terminal nodes, and establishes corresponding tags or equivalent metadata records for subsequent scheduling decisions and monitoring strategy execution. For nodes using the RISC-V instruction set architecture, the platform marks their architectural characteristics and adaptation capabilities in the node metadata so that applications optimized for RISC-V can be accurately scheduled to the corresponding nodes.

[0068] This embodiment constructs an integrated cloud-edge-device platform based on cloud-native technology. It uniformly manages heterogeneous nodes with multiple instruction sets, including general-purpose processors and RISC-V, within the same cluster. By introducing a role distinction between compute nodes and service nodes at the edge, it achieves separation of computation and service. Combined with a lightweight performance monitoring device and a scheduling strategy tailored to cloud-edge-device scenarios, tasks can be aware of node hierarchy, network status, and hardware capabilities during scheduling, and can dynamically adjust deployment locations based on real-time performance metrics, thus balancing performance, latency, and multi-tenant isolation requirements. Simultaneously, this embodiment deploys a Web integrated development environment within the cluster, integrating source code management, cross-compilation, image building, deployment, and operational monitoring onto a single platform. This allows developers to complete a complete closed loop from application design, development, debugging to large-scale deployment and operational optimization around the same cluster. The platform's comprehensive advantages in resource utilization, system stability, and development efficiency have been verified in typical cloud-edge-device application scenarios such as smart homes and drone swarms.

[0069] Figure 7This invention illustrates a heterogeneous cloud-edge-device testbed computing scheduling system 100 based on a RISC-V architecture, comprising a control plane 10, a data plane 20, and a development plane 30; wherein:

[0070] The control plane 10 is deployed on the cloud side to maintain cluster status and metadata, and to make task scheduling decisions based on node roles, instruction set architecture, operational metric data and business topology dependencies.

[0071] The data plane 20 is communicatively connected to the control plane 10 and includes cloud nodes, edge computing nodes, edge service nodes, and IoT terminal nodes. At least some of the edge computing nodes and / or the edge service nodes are based on the RISC-V instruction set architecture, and the edge computing nodes and edge service nodes form a computing and service separation operation structure. Each node of the data plane is equipped with a lightweight indicator monitoring device for collecting operation indicator data locally on the node and reporting it to the control plane. The operation indicator data includes at least one of the following: CPU utilization, memory usage, network bandwidth, and network latency.

[0072] The nodes in data plane 20 are configured with registration interfaces for reporting processor architecture, capabilities, roles, and levels. The control plane is configured with a manager for tagging RISC-V node architecture characteristics based on the reported information. The edge computing nodes are used to carry compute-intensive tasks, and the edge service nodes are used to carry service-responsive tasks. The lightweight metric monitoring device is configured with a data compression or aggregation unit for processing the operational metric data to be reported.

[0073] Development Plane 30 is deployed within the system as a web-based integrated development environment that supports cross-compilation of multiple instruction sets and remote debugging, providing an integrated development process from code writing to deployment and verification. Furthermore, Development Plane 30 supports cross-compilation, image building, and remote debugging for multiple instruction set architectures, including x86, ARM64, and RISC-V, and offers one-click deployment and rollback functionality across different node levels.

[0074] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of the present invention is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0075] Of course, the present invention may have other various embodiments. Without departing from the spirit and essence of the present invention, those skilled in the art can make various corresponding changes and modifications according to the present invention, but these corresponding changes and modifications should all fall within the protection scope of the appended claims.

Claims

1. A computation scheduling method for a heterogeneous cloud-edge-device test field based on RISC-V architecture, characterized in that, Including the following steps: Construct a cloud-native cluster, which includes cloud nodes, edge computing nodes, edge service nodes, and IoT terminal nodes; wherein at least some of the edge computing nodes and / or the edge service nodes are based on the RISC-V instruction set architecture. The edge computing nodes and the edge service nodes are assigned roles to form an operational structure that separates computing and services; wherein, in the operational structure, computing-intensive tasks are assigned to the edge computing nodes, and service-responsive tasks are deployed on the edge service nodes; A lightweight metric monitoring device is deployed on each node of the cloud-native cluster. The lightweight metric monitoring device is used to collect operational metric data locally on the node. A web integrated development environment supporting cross-build and remote debugging of multiple instruction sets is deployed within the cloud-native cluster. The web integrated development environment is used to provide an integrated development process from code writing to deployment and verification. The scheduler makes task scheduling decisions based on the partitioned node roles, instruction set architecture, the aforementioned operational metric data, and business topology dependencies.

2. The method according to claim 1, characterized in that, The operational metrics data include at least one of the following: CPU utilization, memory usage, network bandwidth, and network latency.

3. The method according to claim 1, characterized in that, The web-based integrated development environment supports cross-compilation, image building, and remote debugging for multiple instruction set architectures such as x86, ARM64, and RISC-V, and provides the function of one-click deployment and rollback on different level nodes.

4. The method according to claim 1, characterized in that, The lightweight indicator monitoring device will report the collected operational indicator data to the control plane in a compressed or aggregated manner.

5. A heterogeneous cloud-edge-device testbed computing scheduling system based on RISC-V architecture, characterized in that, It includes a control plane, a data plane, and a development plane; among which: The control plane, deployed on the cloud side, is used to maintain cluster status and metadata, and to execute task scheduling decisions based on node roles, instruction set architecture, operational metric data, and business topology dependencies. The data plane, which is communicatively connected to the control plane, includes cloud nodes, edge computing nodes, edge service nodes, and IoT terminal nodes. At least some of the edge computing nodes and / or the edge service nodes are based on the RISC-V instruction set architecture, and the edge computing nodes and edge service nodes form a computing and service separation operation structure. Each node of the data plane is equipped with a lightweight indicator monitoring device for collecting operational indicator data locally and reporting it to the control plane. The development plane, deployed within the system, is a web-based integrated development environment that supports cross-construction of multiple instruction sets and remote debugging, providing an integrated development process from code writing to deployment and verification.

6. The system according to claim 5, characterized in that, The nodes in the data plane are configured with a registration interface for reporting processor architecture, capabilities, roles, and levels, and the control plane is configured with a manager for marking RISC-V node architecture characteristics based on the reported information.

7. The system according to claim 5, characterized in that, The edge computing nodes are used to carry out computationally intensive tasks, and the edge service nodes are used to carry out service response tasks.

8. The system according to claim 5, characterized in that, The operational metrics data include at least one of the following: CPU utilization, memory usage, network bandwidth, and network latency.

9. The system according to claim 5, characterized in that, The lightweight indicator monitoring device is equipped with a data compression or aggregation unit for processing the operational indicator data to be reported.

10. The system according to claim 5, characterized in that, The development plane supports cross-compilation, image building, and remote debugging for multiple instruction set architectures such as x86, ARM64, and RISC-V, and provides the function of one-click triggering deployment and rollback on different level nodes.

Images