Embedded heterogeneous SoC hardware resource transparent deployment system and method based on Docker

Abstract

The invention provides a Docker-based embedded heterogeneous SoC hardware resource transparent deployment system and method, and relates to the technical field of embedded edge computation.According to the system, a hardware transparent layer is constructed between a Host system and a Docker container, and the system comprises a platform recognition module, a hardware abstract interface module, a dynamic library loading module, a container inside and outside communication module and a security isolation module; by means of the method, the application in the Docker container can call hardware resources such as NPU / VPU in a cross-platform mode through a unified API without modifying codes, one-time construction and multi-platform operation are achieved, and the effects that application developers only need to maintain a single code library, new platform adaptation only needs to expand a hardware transparent layer module, the deployment efficiency is improved by 60% or above, and the hardware resource utilization rate difference is controlled within 5% are achieved.

Description

Technical Field

[0001] The present invention relates to the field of embedded edge computing technology, and in particular to a Docker-based embedded heterogeneous SoC hardware resource transparent deployment system and method. Background Art

[0002] In the field of embedded edge computing, heterogeneous system-on-chips (SoCs) such as Rockchip RK3588 and HiSilicon SS928 are widely used in high-computing scenarios such as neural network reasoning and video encoding and decoding due to their integrated dedicated hardware acceleration units such as neural processing units (NPUs) and video processing units (VPUs). However, current technical solutions have the following core issues:

[0003] (1) Fragmentation of hardware resource calls: The underlying drivers and software development kit (SDK) interfaces of hardware modules (such as NPU / VPU) from different SoC vendors vary significantly (for example, Rockchip's RKNN Toolkit is incompatible with HiSilicon's HiMPP), resulting in application development requiring repeated adaptation for each platform. The traditional deployment process requires separate configuration of the Linux kernel and file system dependencies for each SoC platform, as well as recompilation of application code, significantly extending the development cycle and increasing maintenance costs.

[0004] (2) Limitations of existing containerization technologies: While container technologies such as Docker can isolate application environments, they cannot abstract heterogeneous hardware resource access interfaces. Applications within containers still need to directly call vendor-specific SDKs, resulting in a strong coupling of container images with specific SoC platforms, violating the “build once, run anywhere” principle.

[0005] Although the virtual machine (VM) solution can shield hardware differences, it requires virtualizing the entire operating system, resulting in excessive resource usage and making it difficult to meet the deployment needs of resource-constrained edge devices.

[0006] (3) Lack of standardized hardware abstraction layer: There are mature hardware abstraction solutions in the general computing field (such as CUDA's unified management of graphics processing units (GPUs)), but the acceleration units such as NPU / VPU of embedded SoCs lack industry-level interface standards, and existing containerization solutions cannot be directly reused.

[0007] These issues lead to efficiency bottlenecks when deploying edge computing devices on multiple platforms: applications must maintain multiple code branches for different SoCs, and the adaptation cycle for new hardware platforms can take weeks. Therefore, a lightweight, highly compatible, and unified deployment method for heterogeneous hardware resources is urgently needed. Summary of the Invention

[0008] To this end, an embodiment of the present invention provides a Docker-based embedded heterogeneous SoC hardware resource transparent deployment system and method, which is used to solve the problems in the prior art of high cross-platform adaptation costs and the inability of containerized deployment to uniformly call heterogeneous hardware resources due to the fragmentation of dedicated hardware interfaces such as NPU / VPU of different SoC platforms (such as RK3588 / SS928).

[0009] To solve the above problems, an embodiment of the present invention provides a Docker-based embedded heterogeneous SoC hardware resource transparent deployment system, including:

[0010] Host (host operating system), deployed on the operating system of the embedded device, including hardware drivers and manufacturer SDK libraries;

[0011] The hardware transparency layer runs as a daemon process on the host system and includes a platform identification module, a hardware abstraction interface module, a dynamic library loading module, an intra-container communication module, and a security isolation module.

[0012] Container, run at least one Docker container with a hardware transparent layer client and unified API library pre-installed in the container.

[0013] Preferably, the platform identification module automatically identifies the SoC platform type in the following manner:

[0014] Parse the chip ID in the device tree;

[0015] Read SoC specific register values;

[0016] Matches predefined hardware feature identifiers.

[0017] Preferably, the hardware abstraction interface module defines a standardized API for heterogeneous hardware operations, including:

[0018] NPU inference interface infer(image);

[0019] VPU codec interface encode_h265(stream) / decode_h265(stream);

[0020] Sensor control interface sensor_read().

[0021] Preferably, the dynamic library loading module executes:

[0022] Based on the platform identification results, the SDK library of the corresponding SoC manufacturer is loaded from the host system;

[0023] Map the SDK function address to the virtual interface in the container.

[0024] Preferably, the communication module inside and outside the container implements data interaction in at least one of the following ways:

[0025] Inter-process communication based on Unix Socket;

[0026] High-throughput data exchange is achieved through shared memory.

[0027] Preferably, the security isolation module ensures system security through the following mechanisms:

[0028] Use Docker's namespace isolation technology to limit the container's direct access to the host hardware;

[0029] Through permission control policies, hardware resource call requests between containers are isolated.

[0030] An embodiment of the present invention further provides a method for transparently deploying embedded heterogeneous SoC hardware resources based on Docker. The method uses the above-mentioned embedded heterogeneous SoC hardware resource transparent deployment system based on Docker, and includes the following steps:

[0031] Step S1: pre-install the multi-platform SDK library in the host system and start the hardware transparency layer daemon process;

[0032] Step S2: Build a unified Docker container image, which only contains the hardware transparent layer client and the unified API library;

[0033] Step S3: When the container starts, the hardware transparent layer dynamically injects the corresponding SDK dependency based on the current SoC platform;

[0034] Step S4: The application in the container calls the hardware function through the unified API, and the hardware transparent layer routes the request to the host system for execution.

[0035] Preferably, the unified container image is constructed using Docker multi-stage compilation:

[0036] The first stage compiles the application code and links to the unified API library;

[0037] The second phase will strip away platform-related SDKs, leaving only lightweight clients.

[0038] Preferably, the dynamic injection includes:

[0039] Declare the list of supported platforms via environment variables;

[0040] Download platform-specific configuration files from the host system or the cloud on demand.

[0041] An embodiment of the present invention also provides a computer storage medium, which stores a computer software product. The computer software product includes several instructions for enabling a computer device to execute the above-mentioned Docker-based embedded heterogeneous SoC hardware resource transparent deployment method.

[0042] It can be seen from the above technical solutions that the present invention has the following beneficial effects:

[0043] (1) The cross-platform adaptation cost is significantly reduced: Through the hardware transparent layer, the NPU / VPU and other hardware operations of different SoCs (such as RK3588 / SS928) are encapsulated into a unified API interface (such as infer(image), encode_h265(stream)), combined with the dynamic library loading mechanism to match the corresponding manufacturer SDK (such as RKNN Toolkit, HiMPP) in real time, so that applications in the container can call hardware resources across platforms without modifying the code, realizing "one-time build, multi-platform operation". Application developers only need to maintain a single code base, and new platform adaptation only requires expanding the transparent layer SDK module, shortening the development cycle by more than 60%.

[0044] (2) Balancing hardware resource call efficiency and compatibility: Unix Socket and shared memory are used to achieve high-throughput data interaction inside and outside the container, avoiding Docker's direct access restrictions on the underlying hardware. At the same time, the platform identification module automatically parses the device tree, reads the chip register value, and dynamically injects the corresponding platform dependency library and configuration file. Under the premise of ensuring that the difference in resource utilization such as NPU / VPU is controlled within 5%, transparent calls to heterogeneous hardware are achieved to adapt to the real-time requirements in edge computing scenarios.

[0045] (3) Lightweight design adapts to resource-constrained scenarios: The hardware transparency layer runs as a host system daemon process, which greatly reduces resource usage compared to traditional virtual machine solutions. In addition, through Docker namespace isolation and permission control strategies, it achieves secure isolation between containers / hosts and containers / containers. When deployed in embedded devices such as edge computing boxes and AI analysis cameras, it not only meets the efficient utilization of hardware resources but also ensures system robustness and adapts to the limited computing power and storage characteristics of edge devices. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] In order to more clearly illustrate the implementation cases of the present invention or the technical solutions in the prior art, the following briefly describes the drawings required for use in the embodiments. By referring to the drawings, the features and advantages of the present invention will be more clearly understood. The drawings are for illustration only and should not be construed as limiting the present invention in any way. Those skilled in the art can derive other drawings based on these drawings without inventive effort. Among them:

[0047] Figure 1 A block diagram of a Docker-based embedded heterogeneous SoC hardware resource transparent deployment system provided by the present invention;

[0048] Figure 2 This is an architecture diagram of the system of the present invention;

[0049] Figure 3 Schematic diagram of the hardware transparent layer structure of the present invention;

[0050] Figure 4 This is a flowchart of a method for transparent deployment of embedded heterogeneous SoC hardware resources based on Docker provided by the present invention. DETAILED DESCRIPTION

[0051] To make the objectives, technical solutions, and advantages of the embodiments of the present invention more clear, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. All other embodiments obtained by ordinary technicians in this field based on the embodiments of the present invention without making any creative efforts shall fall within the scope of protection of the present invention.

[0052] Example 1

[0053] In order to solve the problems in the existing technology of high cross-platform adaptation cost and inability of containerized deployment to uniformly call heterogeneous hardware resources due to the fragmentation of dedicated hardware interfaces such as NPU / VPU of different SoC platforms (such as RK3588 / SS928), such as Figure 1 As shown, the present invention proposes a Docker-based embedded heterogeneous SoC hardware resource transparent deployment system, including:

[0054] Host system, deployed on the operating system of the embedded device, including hardware drivers and manufacturer SDK libraries;

[0055] The Hardware Abstraction Layer (HAL) runs as a daemon process on the host system and includes a platform identification module, a hardware abstraction interface module, a dynamic library loading module, an intra-container communication module, and a security isolation module.

[0056] Container, run at least one Docker container with a hardware transparent layer client and unified API library pre-installed in the container.

[0057] As can be seen from the above technical solution, the present invention proposes a Docker-based embedded heterogeneous SoC hardware resource transparent deployment system. By building a hardware transparency layer between the host system and the Docker container, it includes a platform identification module (automatically reading the chip ID, device tree, or register value to identify platforms such as RK3588 / SS928), a hardware abstraction interface module (defining unified APIs such as infer (image) to shield vendor SDK differences), a dynamic library loading module (dynamically loading the corresponding SDK according to the platform and mapping it to the container virtual interface), an intra-container communication module (using Unix Sockets and shared memory to achieve high-throughput data exchange), and a security isolation module (preventing the spread of container failures through namespace and permission control). This allows applications within the Docker container to call hardware resources such as NPUs / VPUs across platforms through a unified API without modifying the code, achieving "one-time build, multi-platform operation". Application developers only need to maintain a single code base, and adapting to new platforms only requires expanding the hardware transparency layer module. This improves deployment efficiency by more than 60% and keeps hardware resource utilization differences within 5%.

[0058] Furthermore, if Figure 2 As shown, the Host system of the present invention is deployed on the operating system of the embedded device (such as Ubuntu, Hongmeng, OpenEuler, etc.), and the specific implementation includes:

[0059] Pre-installed hardware drivers and vendor SDK libraries for various platforms, such as Rockchip's RKNN Toolkit and HiSilicon's HiMPP, are stored in a specified path on the host system (e.g., / usr / local / sdk / ).

[0060] Configure system environment variables to ensure that the hardware transparency layer daemon can access the underlying driver interface (for example, interacting with SoC hardware through libusb or ioctl interfaces).

[0061] Furthermore, the hardware transparency layer of the present invention runs in the Host system as a daemon process (hardware_hal_daemon), which includes five core modules, such as Figure 3 As shown, the specific implementation is as follows:

[0062] 1. Platform identification module

[0063] Technical solution:

[0064] Parse the chip ID node (such as the compatible field) in the device tree file (located in / proc / device-tree / ), for example, by matching the "rockchip,rk3588" or "hisilicon,ss928" strings to identify the platform.

[0065] Read SoC specific register values ​​and access the system management controller (such as the PMU register of RK3588 or the CPUID register of SS928) through the ioctl interface to obtain hardware characteristics.

[0066] Match predefined hardware feature identifiers, for example, by reading the contents of the / sys / firmware / devicetree / base / model file and comparing it with a preset list (["RK3588","SS928","Jetson"]).

[0067] The present invention realizes automatic platform adaptation without manual intervention at startup, avoids manual configuration errors, and shortens deployment time.

[0068] 2. Hardware Abstract Interface Module

[0069] Technical solution:

[0070] Define a standardized API interface, implemented through a C / C++ dynamic library (libhal_api.so), specifically including:

[0071] NPU inference interface: intinfer(const unsigned char*image,int width,int height,int channel,float*result), inputs image data and outputs inference results.

[0072] VPU codec interface: int encode_h265(const unsigned char*stream,int size,unsigned char*encoded_data) and int decode_h265(const unsigned char*encoded_data,int size,unsigned char*stream), handles video stream encoding and decoding.

[0073] Sensor control interface: int sensor_read(int sensor_id,void*data), supports MIPI interface sensor data reading.

[0074] The unified API is converted into the underlying vendor SDK call through the function pointer mapping mechanism within the interface (for example, the infer interface is mapped to RKNN's rknn_run or HiAI's hiai_inference).

[0075] The present invention can shield the underlying differences between SDKs of manufacturers such as Rockchip and HiSilicon. Application developers do not need to pay attention to the interface differences between RKNNToolkit and HiMPP, and the code reuse rate is increased by more than 90%.

[0076] 3. Dynamic library loading module

[0077] Technical solution:

[0078] After platform identification, dynamically load the SDK library of the corresponding SoC manufacturer through dlopen, for example:

[0079] If it is identified as RK3588, load / usr / local / sdk / rknn / lib / librknn_api.so.

[0080] If it is identified as SS928, load / usr / local / sdk / himpp / lib / libhimpp.so.

[0081] Get the SDK function address through dlsym and map it to the virtual interface table (struct HAL_FunctionTable) in the container. For example, map the rknn_init function address to the hal_npu_init interface.

[0082] When the container is started, the current platform information is passed through the environment variable (HAL_PLATFORM), and the dynamic library loading module selects the loaded SDK library based on this information.

[0083] The container image of the present invention does not need to pre-install multi-platform SDKs, and the image size is reduced by more than 60% (for example, the traditional solution image is about 1.2GB, while this solution only requires 0.4GB), reducing storage occupancy and transmission bandwidth.

[0084] 4. Communication module inside and outside the container

[0085] Technical solution:

[0086] Unix Socket (located at / var / run / hal_socket) is used to implement control instruction interaction. For example, the application in the container sends an NPU inference request to the host transparent layer.

[0087] High-throughput data exchange is achieved through shared memory (using shm_open to create a shared memory segment, such as / hal_shm_0). For example, when transmitting video stream data, data can be read / written directly in the shared memory to avoid multiple copies.

[0088] The communication protocol uses a custom binary format that includes fields such as instruction type, data length, and check code to ensure data transmission reliability.

[0089] This invention circumvents the restrictions on Docker's direct access to hardware devices, and improves data throughput to three times that of traditional Socket solutions (the measured 1080P video transmission rate reaches 120MB / s), meeting real-time requirements.

[0090] 5.Safety isolation module

[0091] Technical solution:

[0092] Use Docker's namespace isolation technology to limit the container's direct access to the host hardware. For example, use pid namespace to isolate the process space and device namespace to limit device node access.

[0093] Through permission control policies (based on AppArmor or SELinux), independent hardware access rules are configured for each container. For example, only container A is allowed to access the NPU, and container B is allowed to access the VPU.

[0094] Realize resource isolation between containers / hosts and containers / containers. When a container crashes due to hardware call exceptions, it will not affect the operation of the host system and other containers.

[0095] The present invention can prevent a single container failure from affecting the host or other containers, thereby improving system robustness. Tests have shown that the system can run continuously for 1,000 hours without any failure spreading.

[0096] Furthermore, the container of the present invention pre-installs a hardware transparent layer client (hal_client.so) and a unified API library (libhal_api.so), and the client communicates with the host transparent layer through Unix Socket or shared memory. The container image adopts a lightweight design and only contains application code, a hardware transparent layer client and necessary runtime libraries, and does not contain a platform-specific SDK. When the container starts, the hardware transparent layer is informed of the current target platform through an environment variable (such as HAL_PLATFORM=RK3588), triggering dynamic dependency injection.

[0097] Example 2

[0098] like Figure 4As shown, the present invention provides a method for transparent deployment of embedded heterogeneous SoC hardware resources based on Docker, which uses the above-mentioned embedded heterogeneous SoC hardware resource transparent deployment system based on Docker, including the following steps:

[0099] Step S1: pre-install the multi-platform SDK library in the host system and start the hardware transparency layer daemon process;

[0100] Step S2: Build a unified Docker container image, which only contains the hardware transparent layer client and the unified API library;

[0101] Step S3: When the container starts, the hardware transparent layer dynamically injects the corresponding SDK dependency based on the current SoC platform;

[0102] Step S4: The application in the container calls the hardware function through the unified API, and the hardware transparent layer routes the request to the host system for execution.

[0103] Specifically, in step S1, the host system is pre-configured and the hardware transparency layer is started. First, the SDK libraries are stored by platform in the / usr / local / sdk / directory of the host system. Then, the hardware transparency layer daemon is started. After startup, the daemon listens to the Unix socket ( / var / run / hal_socket) and initializes the pre-loaded environment for each platform's SDK.

[0104] Specifically, in step S2, a unified Docker container image is built. This method uses Docker's multi-stage compilation process. The first stage compiles the application code and links to a unified API library. The second stage strips away platform-specific SDKs, leaving only the lightweight client. Furthermore, when building the image, the --build-arg parameter specifies a list of supported platforms.

[0105] Specifically, in step S3, SDK dependencies are dynamically injected when the container is started. When the container is started, the hardware transparent layer daemon receives the container start request and executes according to the HAL_PLATFORM environment variable:

[0106] Read the configuration file rknn_config.json from / usr / local / sdk / rk3588 / config / and inject it into the container environment.

[0107] Use shared memory to map the memory area required by the SDK (such as the NPU model cache).

[0108] Create a virtual device node (such as / dev / rknn) in the container and map it to the actual driver interface of the host.

[0109] Specifically, in step S4, the application in the container calls the hardware function through a unified API. After receiving the hal_npu_infer call, the hardware transparent layer converts the request into an underlying call to RKNN based on the current platform (such as RK3588), performs the actual inference operation, and returns the result to the container application through shared memory.

[0110] The present embodiment provides a method for transparent deployment of embedded heterogeneous SoC hardware resources based on Docker, which uses the aforementioned system for transparent deployment of embedded heterogeneous SoC hardware resources based on Docker. Therefore, the specific implementation method of the method for transparent deployment of embedded heterogeneous SoC hardware resources based on Docker can be found in the embodiment section of the system for transparent deployment of embedded heterogeneous SoC hardware resources based on Docker. In order to avoid redundancy, it will not be repeated here.

[0111] Specific case: Deploying the YOLOv5 model on the RK3588 and SS928 platforms

[0112] 1. Case Background

[0113] In an edge computing scenario, the YOLOv5 target detection model needs to be deployed on different hardware platforms (RK3588 and SS928). Traditional solutions require separate compilation of applications for each platform. This case uses the system of the present invention to achieve unified deployment.

[0114] 2. Specific implementation process

[0115] Host system preparation:

[0116] The RKNN Toolkit SDK is stored in the Host system of the RK3588 device, and the HiMPPSDK is stored in the SS928 device.

[0117] Start the hardware transparency layer daemon process and run it on both devices.

[0118] Build a unified image:

[0119] Use the above Dockerfile to build an image, which does not include any platform-specific SDKs. The image size is approximately 400MB.

[0120] Container deployment:

[0121] Start the container on the RK3588 device, set HAL_PLATFORM=RK3588, load the RKNN library in the transparent layer, and call the NPU through hal_npu_infer. The measured inference speed is 220FPS.

[0122] Start the same image on the SS928 device and set HAL_PLATFORM=SS928. The transparent layer automatically switches to the HiAI engine without modifying the application code. The measured inference speed is 200FPS.

[0123] 3. Technical effect verification

[0124] Deployment efficiency: Traditional solutions require two days to complete dual-platform adaptation, while this solution only takes two hours, an improvement of more than 60%.

[0125] Resource utilization: The difference in NPU resource utilization between the RK3588 and SS928 platforms is controlled within 3.2%, meeting business consistency requirements.

[0126] Code maintenance: The application team only needs to maintain one code base. When adapting to a new platform (such as NVidia Jetson), they only need to expand the SDK adaptation module of the transparent layer without modifying the application code.

[0127] Furthermore, the technology of the present invention can be introduced into the following products:

[0128] Edge computing boxes: such as industrial-grade edge computing devices, support the deployment of AI inference applications on multiple SoC platforms.

[0129] AI Analysis Box: used for real-time target detection and analysis in video surveillance scenarios.

[0130] AI analysis camera: An intelligent camera with integrated NPU / VPU to achieve local image recognition.

[0131] Edge computing analysis device: deployed on the IoT gateway to process sensor data.

[0132] Analysis server: A miniaturized edge server that supports multi-task parallel computing.

[0133] Through the above-mentioned specific implementation methods, the present invention realizes the transparent deployment of embedded heterogeneous SoC hardware resources, solves the problems of difficult multi-platform adaptation and long development cycle in the existing technology, and provides an efficient and unified solution for edge computing scenarios.

[0134] Example 3:

[0135] An embodiment of the present invention provides a computer storage medium storing a computer software product. The computer software product includes several instructions for enabling a computer device to execute the above-mentioned method for transparent deployment of embedded heterogeneous SoC hardware resources based on Docker.

[0136] Those skilled in the art will appreciate that the embodiments of the present application can be provided as methods, systems, or computer program products. Therefore, the present application can adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application can adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) that contain computer-usable program code.

[0137] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the steps in the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0138] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 These computer program instructions can also be loaded onto a computer or other programmable data processing device, so that a series of operation steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process in the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0139] Obviously, the above embodiments are merely examples for clarity of explanation and are not intended to limit the implementation methods. Those skilled in the art will appreciate that other variations or modifications can be made based on the above description. It is not necessary and impossible to enumerate all implementation methods here. Obvious variations or modifications arising therefrom remain within the scope of protection of the present invention.

Claims

1. A Docker-based embedded heterogeneous SoC hardware resource transparent deployment system, characterized by: include: Host system, deployed on the operating system of the embedded device, including hardware drivers and manufacturer SDK libraries; The hardware transparency layer runs as a daemon process on the host system and includes a platform identification module, a hardware abstraction interface module, a dynamic library loading module, an intra-container communication module, and a security isolation module. Container, run at least one Docker container with a hardware transparent layer client and unified API library pre-installed in the container.

2. The embedded heterogeneous SoC hardware resource transparent deployment system based on Docker according to claim 1 is characterized in that: The platform identification module automatically identifies the SoC platform type in the following ways: Parse the chip ID in the device tree; Read SoC specific register values; Matches predefined hardware feature identifiers.

3. The embedded heterogeneous SoC hardware resource transparent deployment system based on Docker according to claim 1, characterized in that: The hardware abstraction interface module defines a standardized API for heterogeneous hardware operations, including: NPU inference interface infer(image); VPU codec interface encode_h265(stream) / decode_h265(stream); Sensor control interface sensor_read().

4. The embedded heterogeneous SoC hardware resource transparent deployment system based on Docker according to claim 1, characterized in that: The dynamic library loading module executes: Based on the platform identification results, the SDK library of the corresponding SoC manufacturer is loaded from the host system; Map the SDK function address to the virtual interface in the container.

5. The embedded heterogeneous SoC hardware resource transparent deployment system based on Docker according to claim 1, characterized in that: The communication module inside and outside the container implements data interaction using at least one of the following methods: Inter-process communication based on Unix Socket; High-throughput data exchange is achieved through shared memory.

6. The embedded heterogeneous SoC hardware resource transparent deployment system based on Docker according to claim 1, characterized in that: The security isolation module ensures system security through the following mechanisms: Use Docker's namespace isolation technology to limit the container's direct access to the host hardware; Through permission control policies, hardware resource call requests between containers are isolated.

7. A method for transparent deployment of embedded heterogeneous SoC hardware resources based on Docker, characterized in that: The method uses the embedded heterogeneous SoC hardware resource transparent deployment system based on Docker according to any one of claims 1 to 6, comprising the following steps: Step S1: pre-install the multi-platform SDK library in the host system and start the hardware transparency layer daemon process; Step S2: Build a unified Docker container image, which only contains the hardware transparent layer client and the unified API library; Step S3: When the container starts, the hardware transparent layer dynamically injects the corresponding SDK dependency based on the current SoC platform; Step S4: The application in the container calls the hardware function through the unified API, and the hardware transparent layer routes the request to the host system for execution.

8. The method for transparent deployment of embedded heterogeneous SoC hardware resources based on Docker according to claim 7, characterized in that: The unified container image is built using Docker multi-stage compilation: The first stage compiles the application code and links to the unified API library; The second phase will strip away platform-related SDKs, leaving only lightweight clients.

9. The method for transparent deployment of embedded heterogeneous SoC hardware resources based on Docker according to claim 7, characterized in that: The dynamic injection includes: Declare the list of supported platforms via environment variables; Download platform-specific configuration files from the host system or the cloud on demand.

10. A computer storage medium, characterized in that The computer storage medium stores a computer software product, which includes several instructions for enabling a computer device to execute the Docker-based embedded heterogeneous SoC hardware resource transparent deployment method described in any one of claims 7 to 9.

Images