Unified peripheral management method and device

Abstract

The application provides a unified peripheral management method and device, the method comprises the following steps: constructing a unified peripheral management server based on a cross-process communication mechanism; obtaining peripheral hardware attribute information of an embedded device, a peripheral access request of a multi-process business client and client access attribute information through the server; instantiating and managing a plurality of peripherals according to the peripheral hardware attribute information to determine a target peripheral pointed by the request; and performing multi-dimensional control on the current access process of the multi-process business client to the target peripheral according to the peripheral hardware attribute information, the client access attribute information and current system state information. The application reduces system resource occupation through an on-demand starting mechanism and an automatic resource recycling strategy, realizes fault isolation of input and output devices through a double-process service architecture, the framework can be adapted to deployment of various operating systems, and the order, safety and efficiency of multi-concurrent peripheral access are improved.

Description

Technical Field

[0001] This application relates to the field of electrical digital data processing or general control or regulation system technology, and in particular to a unified peripheral management method and device. Background Technology

[0002] As embedded systems evolve towards multi-domain convergence and centralized computing architectures, high-end embedded devices in fields such as automotive, industrial control, and medical applications generally adopt a productization model that uses a single hardware platform compatible with multiple mainstream operating systems (such as choosing to deploy different operating systems like Linux, Android, and HarmonyOS based on business needs) to simultaneously meet the differentiated requirements of various scenarios in terms of real-time performance, security, and functionality. Peripherals, as the core interface for interaction between embedded systems and the physical world, require efficient and secure management, which is a crucial foundation for ensuring the collaborative operation of multiple business processes.

[0003] Currently, embedded devices compatible with multiple operating systems generally adopt a fragmented development model where each operating system independently builds its peripheral management system. This model suffers from the following core technical defects: peripheral resources are statically allocated to specific business processes for exclusive use, making global sharing and dynamic scheduling impossible, resulting in low hardware resource utilization; the lack of a globally unified concurrent access scheduling mechanism makes it easy for multiple clients to access the same peripheral simultaneously, leading to data corruption, access conflicts, and timing disorders; fragmented and coarse-grained security isolation capabilities pose a security risk of low-security-level business processes accessing high-security-level peripherals without authorization, failing to meet the mandatory security requirements of high-reliability domains; inconsistent hot-swapping mechanisms easily lead to driver conflicts, resource leaks, and system crashes; and peripheral drivers and management code need to be repeatedly developed and adapted for different operating systems, resulting in high R&D and maintenance costs and low product iteration efficiency.

[0004] Therefore, how to achieve unified, efficient, and secure management of peripheral resources, while significantly improving hardware resource utilization, system stability and security, and greatly reducing R&D and maintenance costs, has become a core technical problem that urgently needs to be solved in this field. Summary of the Invention

[0005] This application provides a unified peripheral management method and device. By constructing a unified peripheral management server based on a cross-process communication mechanism, it uniformly takes over all peripheral management permissions within the currently running operating system, centrally receives peripheral access requests from multi-process business clients, and performs global unified instantiation management and multi-dimensional coordinated control of all peripheral resources. This enables global sharing and orderly and secure access to peripheral resources, significantly improving hardware resource utilization, system stability, and security.

[0006] In a first aspect, embodiments of this application provide a unified peripheral management method applied to an embedded device, wherein the embedded device is configured with multiple peripheral interfaces, and the method includes: A unified peripheral device management server is built based on a cross-process communication mechanism. The server adopts a dual-process service architecture, including a sensor service process and a hardware component service process, which are respectively responsible for the centralized management of input devices and output devices, and realize fault isolation between input devices and output devices. The server obtains peripheral hardware attribute information of the embedded device, peripheral access requests of multi-process business clients in the currently running operating system, and corresponding client access attribute information. Based on the peripheral hardware attribute information, the server performs instantiation management on multiple peripherals to determine the target peripheral to which the peripheral access request points. The instantiation management includes an on-demand startup mechanism, which is used to start the device hardware resources when the first client registers a callback, and to automatically stop the device and release resources when all clients disconnect. Based on the peripheral hardware attribute information, the client access attribute information, and the system status information of the currently running operating system, the server performs multi-dimensional control over the current access process of the multi-process business client to the target peripheral. The multi-dimensional control includes permission verification control with execution priority from high to low, access timing scheduling control and hot-plug control, as well as cross-process communication protocol standardization control based on a unified transaction coding system.

[0007] Secondly, embodiments of this application provide a unified peripheral management device applied to an embedded device, wherein the embedded device is configured with multiple peripheral interfaces; the device includes a first processing module, an acquisition module, and a second processing module, wherein: The first processing module is used to build a unified peripheral device management server based on a cross-process communication mechanism. The server adopts a dual-process service architecture, including a sensor service process and a hardware component service process, which are respectively responsible for the centralized management of input devices and output devices, and realize fault isolation between input devices and output devices. The acquisition module is used to acquire peripheral hardware attribute information of the embedded device, peripheral access requests of multi-process business clients in the currently running operating system, and corresponding client access attribute information through the server. The second processing module is used to instantiate and manage multiple peripherals through the server based on the peripheral hardware attribute information to determine the target peripheral to which the peripheral access request points. The instantiation management includes an on-demand startup mechanism, which starts the device hardware resources when the first client registers a callback and automatically stops the device and releases resources when all clients disconnect. Based on the peripheral hardware attribute information, the client access attribute information, and the system status information of the currently running operating system, the module performs multi-dimensional control over the current access process of the multi-process business client to the target peripheral through the server. The multi-dimensional control includes permission verification control with execution priority from high to low, access timing scheduling control and hot-plug control, as well as cross-process communication protocol standardization control based on a unified transaction coding system.

[0008] Thirdly, embodiments of this application provide an embedded device, including a processor, a memory, a communication interface, and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the processor, and the programs include instructions for performing steps in any method of the first aspect of this application.

[0009] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program for electronic data interchange, wherein the computer program causes a computer to perform some or all of the steps described in any method of the first aspect of this application.

[0010] Fifthly, embodiments of this application provide a computer program product, wherein the computer program product includes a non-transitory computer-readable storage medium storing a computer program operable to cause a computer to perform some or all of the steps described in any method of the first aspect of this application. The computer program product may be a software installation package.

[0011] By implementing the embodiments of this application, a single unified peripheral management server can centrally take over the management permissions of all peripherals within the currently running operating system. This breaks the traditional fragmented development model where each operating system independently builds its own peripheral management system. It enables a unified peripheral management code to be deployed on multiple mainstream operating systems such as Linux, Android, and HarmonyOS, significantly reducing R&D and maintenance costs. At the same time, the unified server integrates peripheral instantiation management and multi-dimensional coordination and control capabilities, fundamentally solving the problems of concurrent peripheral access conflicts from multiple clients, lack of security isolation, and chaotic handling of hot-plug events, thereby improving the operational stability and security of embedded devices. Attached Figure Description

[0012] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0013] Figure 1 This is a system architecture diagram of a unified peripheral management system provided in an embodiment of this application; Figure 2 This is a schematic diagram illustrating the composition of a unified peripheral management server provided in an embodiment of this application; Figure 3 This is a schematic diagram of the structure of an embedded device provided in an embodiment of this application; Figure 4 This is a flowchart illustrating a unified peripheral management method provided in an embodiment of this application; Figure 5 This is a schematic diagram of a peripheral instantiation management process provided in an embodiment of this application; Figure 6 This is a schematic diagram illustrating a process for verifying and controlling access requests to peripheral devices, provided in an embodiment of this application. Figure 7 This is a schematic diagram of a process for managing the timing of access requests to peripheral devices, provided in an embodiment of this application. Figure 8 This is a schematic diagram of a process for hot-plugging and managing peripherals provided in an embodiment of this application; Figure 9 This is a block diagram of the functional modules of a unified peripheral management device provided in an embodiment of this application. Detailed Implementation

[0014] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0015] The terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or apparatuses.

[0016] It should be understood that the term "and / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this document indicates that the preceding and following related objects are in an "or" relationship. In the embodiments of this application, "multiple" refers to two or more.

[0017] In the embodiments of this application, "at least one item" or its similar expression refers to any combination of these items, including any combination of a single item or a plurality of items. "One or more" means one or more, while "multiple" means two or more. For example, "at least one item" of a, b, or c can represent the following seven cases: a, b, c; a and b; a and c; b and c; a, b, and c. Each of a, b, and c can be an element or a set containing one or more elements.

[0018] In this application, the term "connection" refers to various connection methods, such as direct connection or indirect connection, to achieve communication between devices. This application does not impose any limitations on this.

[0019] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0020] The following is an explanation of the relevant terms used in this application: Inter-process communication (IPC) mechanisms refer to the technical means by which different independent processes exchange data, pass instructions, and synchronize states within the same embedded device. They are fundamental to enabling multi-process collaborative work. The IPC mechanism described in this application is compatible with various mainstream implementations, including the Binder mechanism for Android systems, the Unix Domain Socket and D-Bus mechanisms for Linux-like systems, shared memory mechanisms for high-throughput scenarios, message queue mechanisms for asynchronous message passing, and a general-purpose RPC framework mechanism suitable for cross-language and cross-platform applications. This provides unified communication access capabilities for multi-process business clients running on different heterogeneous operating systems.

[0021] Unified peripheral management server: refers to middleware service running on embedded devices, which centrally takes over the global management permissions of all peripherals, provides a unified peripheral access interface for multi-process business clients, and connects to various peripheral drivers.

[0022] Peripheral instance: refers to the logical abstract object created by the unified peripheral management server for each physical peripheral. It encapsulates the peripheral's hardware attributes, driver interface and running status information, and is the basic unit for the server to manage and schedule peripherals in a unified manner.

[0023] Globally unique service discovery endpoint: refers to the unique global entry point registered by the unified peripheral management service in the system's inter-process communication registry. Clients on the operating system can discover and connect to the unified peripheral management service through this endpoint, which is visible to all clients in the entire system.

[0024] Peripheral instance service endpoint: refers to the exclusive access point that the unified peripheral management server registers separately for each peripheral instance. Clients interact with specific peripherals through this endpoint, which is only visible to clients with corresponding access permissions.

[0025] Cross-process communication namespaces refer to a system mechanism used to isolate communication environments between different processes. It can divide clients with different security levels into independent virtual communication spaces, restrict the range of service endpoints visible to clients in each space, and achieve environment-level security isolation.

[0026] Peripheral access capability set: refers to the set of fine-grained permissions allocated to each multi-process business client. It clearly defines the types of peripherals that the client is allowed to access and the types of operations that it is allowed to perform. It is the core basis for implementing client-level permission control.

[0027] Access Control List (ACL): refers to a set of whitelist rules configured separately for each peripheral instance. It explicitly records the client identifiers allowed to access the peripheral, the allowed operation types, and the access time window. It is the core mechanism for achieving fine-grained management at the peripheral instance level.

[0028] System hardware resource pool: refers to the set of hardware resources that are uniformly managed by the unified peripheral management server and can be dynamically allocated to peripherals. It includes available bus channels, interrupt numbers and memory address spaces, etc., and is used to realize the global scheduling and automatic reclamation of hardware resources.

[0029] Multi-dimensional coordination and control: refers to the comprehensive multi-dimensional control of the entire process of peripheral access by the unified peripheral management server. It integrates three core capabilities: time-series scheduling control, permission verification control, and hot-plug control, as well as standardized control of cross-process communication protocols based on a unified transaction coding system, to ensure the orderliness, security, and dynamic scalability of peripheral access.

[0030] Currently, embedded devices compatible with multiple operating systems generally adopt a fragmented development model where each operating system independently builds its peripheral management system. This model suffers from the following core technical defects: peripheral resources are statically allocated to specific business processes for exclusive use, making global sharing and dynamic scheduling impossible, resulting in low hardware resource utilization; the lack of a globally unified concurrent access scheduling mechanism makes it easy for multiple clients to access the same peripheral simultaneously, leading to data corruption, access conflicts, and timing disorders; fragmented and coarse-grained security isolation capabilities pose a security risk of low-security-level business processes accessing high-security-level peripherals without authorization, failing to meet the mandatory security requirements of high-reliability domains; inconsistent hot-swapping mechanisms easily lead to driver conflicts, resource leaks, and system crashes; and peripheral drivers and management code need to be repeatedly developed and adapted for different operating systems, resulting in high R&D and maintenance costs and low product iteration efficiency.

[0031] Therefore, how to achieve unified, efficient, and secure management of peripheral resources, while significantly improving hardware resource utilization, system stability and security, and greatly reducing R&D and maintenance costs, has become a core technical problem that urgently needs to be solved in this field.

[0032] To address the aforementioned issues, embodiments of this application provide a unified peripheral management method and device.

[0033] For easier understanding, please refer to Figure 1 , Figure 1 This is a system architecture diagram of a unified peripheral management system provided in an embodiment of this application. The unified peripheral management system includes a unified peripheral management server, several peripherals, and a multi-process business client. The multi-process business client includes several clients.

[0034] Among them, the server, as the sole control center of the entire system, connects to all physical peripherals and drivers at the bottom and provides a unified peripheral access point for multi-process business clients in the currently running operating system at the top. It is the core carrier for realizing cross-system peripheral sharing and unified management.

[0035] Several peripherals are used to enable the embedded device to interact with the physical world. These include various types of peripherals such as input and output devices, responsible for collecting external environmental data or executing control commands issued by the system, and interacting with the server. Each peripheral is configured with unique device identification information and instance configuration information.

[0036] Among them, several clients include, but are not limited to: security control clients, human-computer interaction clients, data processing clients, and remote diagnostic clients. Each client runs as an independent process on different heterogeneous operating systems. It can send peripheral access requests to the server according to its business needs and receive peripheral data and status information returned by the server without having to care about the differences in the underlying operating system and the details of the peripheral hardware.

[0037] In this embodiment, the multi-process service client accesses peripheral services through a unified client interface layer. This unified client interface layer is implemented using a proxy pattern, and the specific process includes: Service discovery process: After creating a device client instance, the client constructs a ProxyImpl and calls the getServiceInstance() method; it checks whether the cached instance pointer is connected. If not, it obtains the ServiceManager, searches for the server through the system service manager or a pre-configured address, registers a process termination listener (linkToDeath), executes interface_cast to convert the server interface into a client-available interface, caches the instance pointer, and returns the service proxy; Request processing process: When the client calls a higher-level API, the underlying layer packages and serializes the parameter data, sends a cross-process communication request to the server through the transact method; the server receives the request through the onTransact method, parses the transaction code and parameters, calls the corresponding device instance for processing, serializes the processing result, and returns it to the client; Exception handling mechanism: When service discovery fails, a retry strategy is adopted. If the number of retries exceeds a threshold, an error code is returned; the server's abnormal termination is detected through a process termination listener, automatically cleans up connection resources, and notifies the client to re-initiate service discovery.

[0038] Understandably, after the server starts, it completes driver preloading, resource pool initialization, and service registration. Clients access the server through a unified entry point and are allocated an independent namespace. After security verification and timing scheduling, access requests are processed by the server through peripheral instances to complete data interaction, while hot-plug events are handled in real time.

[0039] For easier understanding, please refer to Figure 2 , Figure 2 This is a schematic diagram illustrating the composition of a unified peripheral management server provided in an embodiment of this application. The unified peripheral management server is deployed on embedded devices (such as vehicle central domain controllers, industrial robot controllers, and medical imaging equipment) and serves as the sole global control hub for the entire unified peripheral management system. Internally, it integrates an operating system abstraction layer, a cross-process communication adaptation layer, a unified core management layer, and a peripheral driver abstraction layer. These layers interact and transmit commands through standardized internal interfaces, collaboratively completing the entire process of peripheral lifecycle management, multi-client request scheduling, permission verification and control, and hot-plug event handling.

[0040] Based on this, the server also establishes a unified transaction coding system and data serialization format, adopts a layered coding strategy to define standardized transaction codes, and implements data serialization based on the Protocol Buffers serialization protocol to ensure the standardization and compatibility of instruction interaction and data transmission between different levels and modules.

[0041] The operating system abstraction layer is responsible for abstracting and shielding the differences in kernel-mode interfaces of various operating systems. It provides a unified and standardized system call interface for all upper-layer modules, covering basic system functions such as thread management, memory allocation, interrupt handling, timers, and bus status monitoring, enabling the server to adapt to multiple operating systems. At the same time, it manages the system hardware resource pool in a unified manner, realizing the global allocation and automatic reclamation of hardware resources such as bus channels, interrupt numbers, and memory address spaces, ensuring that the server can run stably without difference in different operating system environments.

[0042] The cross-process communication adaptation layer is responsible for adapting to and being compatible with various mainstream cross-process communication mechanisms such as D-Bus, Binder, Socket, and shared memory, providing a unified service access entry point for multi-process business clients. At the same time, it realizes the creation and management of cross-process communication namespaces, isolates clients with different security levels in mutually independent virtual communication spaces, restricts the range of service endpoints visible to each client, and provides the lowest-level environment-level security protection for the system.

[0043] The unified core management layer serves as the core scheduling and decision-making hub for the server, integrating four core functional modules: peripheral instance management, permission verification and control, access sequence scheduling and control, and hot-plug management. The peripheral instance management module is responsible for creating and maintaining peripheral instances based on their hardware attributes, achieving unified identification and full lifecycle management of peripherals. The permission verification and control module maintains the client access capability set and peripheral instance access control list, performing four-level sequential permission verification to ensure the security of peripheral access. The access sequence scheduling and control module calculates the peripheral access response sequence for multiple concurrent access requests based on client capability profiles and system load status, ensuring the real-time performance of high-priority services. The hot-plug management module monitors the peripheral bus status in real time, automatically handles peripheral insertion and removal events, and completes resource allocation / reclamation and peripheral instance creation / destruction.

[0044] The peripheral driver abstraction layer is responsible for abstracting and shielding the differences in driver interfaces of different types of peripherals. It connects to the native drivers of various peripherals at the bottom and provides a unified peripheral access abstraction interface for the unified core management layer at the top, covering standard operations such as opening, reading, writing, controlling, and closing. It also supports the preloading and dynamic unloading of peripheral drivers, providing underlying support for hot-plugging functionality and ensuring that the server can seamlessly access various input, output, control, and communication peripherals.

[0045] As can be seen, the unified peripheral management server completely shields the differences between the underlying operating system, communication mechanism and peripheral hardware through a four-layer heterogeneous abstract architecture. Combined with the globally unified multi-dimensional coordination and control capabilities, it achieves compatible deployment of the same architecture on multiple operating systems and unified management of peripheral resources, which significantly improves hardware resource utilization, system stability and security.

[0046] The following is combined Figure 3 The embedded device in the embodiments of this application will be described. Figure 3 This is a schematic diagram of the structure of an embedded device provided in an embodiment of this application, such as... Figure 3 As shown, the embedded device includes one or more processors, a memory, a communication interface, and one or more programs. The processor is connected to the memory and the communication interface via an internal communication bus.

[0047] The processor can be used for: A unified peripheral device management server is built based on a cross-process communication mechanism. The server adopts a dual-process service architecture, including a sensor service process and a hardware component service process, which are respectively responsible for the centralized management of input devices and output devices, and realize fault isolation between input devices and output devices. The server obtains peripheral hardware attribute information of the embedded device, peripheral access requests of multi-process business clients in the currently running operating system, and corresponding client access attribute information. Based on the peripheral hardware attribute information, the server performs instantiation management on multiple peripherals to determine the target peripheral to which the peripheral access request points. The instantiation management includes an on-demand startup mechanism, which is used to start the device hardware resources when the first client registers a callback, and to automatically stop the device and release resources when all clients disconnect. Based on the peripheral hardware attribute information, the client access attribute information, and the system status information of the currently running operating system, the server performs multi-dimensional control over the current access process of the multi-process business client to the target peripheral. The multi-dimensional control includes permission verification control with execution priority from high to low, access timing scheduling control and hot-plug control, as well as cross-process communication protocol standardization control based on a unified transaction coding system.

[0048] The one or more programs are stored in the aforementioned memory and configured to be executed by the aforementioned processor, and the one or more programs include instructions for performing any step in the above method embodiments.

[0049] The processor can be a central processing unit (CPU), a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute the various exemplary logic blocks, cells, and circuits described in conjunction with the disclosure of this application. The processor can also be a combination that implements computational functions, such as a combination of one or more microprocessors, a combination of a DSP and a microprocessor, etc. The communication unit can be a communication interface, transceiver, transceiver circuit, etc., and the storage unit can be a memory.

[0050] The memory can be volatile or non-volatile, or a combination of both. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM), used as an external cache. By way of example, but not limitation, many forms of random access memory (RAM) are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate synchronous DRAM (DDR SDRAM), enhanced synchronous DRAM (ESDRAM), synchronous linked DRAM (SLDRAM), and direct rambus RAM (DR RAM).

[0051] It is understood that embedded devices may include more or fewer structural elements than those shown in the block diagram above, such as power modules, physical buttons, Wi-Fi modules, speakers, Bluetooth modules, sensors, display modules, etc., without limitation. It is understood that this embedded device is as follows: Figure 1 The hardware carrier of the unified peripheral management system has a unified peripheral management server and a multi-process business client running on it.

[0052] After understanding the software and hardware architecture of this application, the following will be combined with... Figure 4 This application describes a unified peripheral management method in its embodiments. Figure 4 This is a flowchart illustrating a unified peripheral management method provided in an embodiment of this application, applied to an embedded device. The embedded device is configured with multiple peripheral interfaces, and the method includes: Step S401: Build a unified peripheral management server based on the cross-process communication mechanism.

[0053] The server adopts a dual-process service architecture, including a sensor service process and a hardware component service process, which are responsible for the centralized management of input devices and output devices respectively, so as to achieve fault isolation between input devices and output devices.

[0054] In one possible embodiment, the construction of a unified peripheral management server based on inter-process communication mechanisms includes: constructing an operating system abstraction layer to provide a unified standardized system call interface, enabling the server to adapt to multiple operating systems; constructing an inter-process communication adaptation layer to provide a unified service access interface for the multi-process business clients, wherein the inter-process communication adaptation layer supports multiple inter-process communication mechanisms, including D-Bus, Binder, Socket, shared memory, message queue mechanisms, and RPC framework mechanisms, wherein the message queue mechanisms include SystemV message queues or POSIX message queues, and the RPC framework mechanisms include gRPC or Thrift; and constructing a unified core management layer to integrate peripheral instantiation management, timing scheduling control, permission verification control, and hot-plug control functional modules. The unified core management layer adopts the dual-process service architecture, where the sensor service process and the hardware component service process run independently, and a failure in one process does not affect the normal operation of the other. A peripheral driver abstraction layer is constructed to encapsulate driver interfaces for different types of peripherals and provide a unified peripheral access interface. A unified transaction coding system and data serialization format are established. The unified transaction coding system adopts a hierarchical coding strategy, with first-level coding representing the major transaction category, second-level coding representing the transaction subclass, and third to sixth-level coding representing specific operation parameters and extended information. The data serialization format is implemented based on the Protocol Buffers serialization protocol. Server-side initialization operations are performed to complete the construction of the unified peripheral management server. The initialization operations include registering a globally unique service discovery endpoint and publishing unified peripheral management service metadata to the currently running operating system.

[0055] Specifically, an operating system abstraction layer is constructed, including: mapping functionally equivalent but interface-different native functions to a standardized set of system calls by writing adaptation layer code for multiple operating systems. For Android, this is achieved through HAL interface encapsulation; for Linux-like systems, daemon processes are developed; Open Harmony adapts the kernel IPC; and for the RTOS, a lightweight message queue is used, enabling core logic to be written once and run on multiple systems.

[0056] Specifically, a cross-process communication adaptation layer is constructed, including: implementing independent adapters for each mainstream IPC mechanism and establishing a bidirectional conversion channel between heterogeneous messages and internal standard messages. After the server starts, it automatically listens to all IPC channels, and clients can access it using the native IPC mechanism; simultaneously, it dynamically adapts to the optimal mechanism based on the system type: Android prioritizes Binder, Linux uses Unix Domain Socket, and high-throughput scenarios employ shared memory zero-copy transmission.

[0057] In this embodiment, a dual-process service architecture is constructed, including deploying the sensor service process as a system-level service, responsible for the centralized management of input devices such as accelerometers, light sensors, analog-to-digital converters, and buttons, realizing data acquisition, event-driven, and sampling interval control functions; and deploying the hardware component service process as a system-level service, responsible for the centralized management of output devices such as LED indicators, buzzers, USB mode switching, and backlight control, realizing status control, command-driven, and operation response functions. The two processes run independently of each other, with independent memory address spaces and error handling domains. A single process failure (such as a sensor service process crash) is restricted to an independent domain through the operating system's process isolation mechanism, preventing abnormal termination of the hardware component service process, thus achieving fault isolation of input and output devices and improving system stability.

[0058] Specifically, a peripheral driver abstraction layer is constructed, employing an object-oriented layered abstract class system to achieve standardized driver adaptation: first, a general peripheral abstract base class is built, and then input and output device abstract base classes are derived. The input device base class defines a standardized interface system, with built-in mechanisms for on-demand startup, exception handling, and instance management; the output device base class uses a predefined opcode set and a general parameter array to construct a unified interface, reserving basic opcode space for subclasses to allocate semantics. This architecture moves common logic to the base class, requiring specific drivers to implement only differentiated functions, reducing development workload and supporting dynamic and seamless integration of new peripherals.

[0059] Specifically, the standardized transaction code set defined by the hierarchical coding strategy includes: Level 1 codes representing transaction categories, including callback management transactions (code 0x10), sensor control transactions (code 0x20), hardware data exchange transactions (code 0x30), status query transactions (code 0x40), keyboard transactions (code 0x50), and command execution transactions (code 0x60); Level 2 codes representing transaction subcategories, for example, under the sensor control transaction category, 0x21 represents the sampling interval setting subcategory, 0x22 represents the enable control subcategory, and 0x23 represents the activation status query subcategory; Levels 3 to 6 codes represent specific operation parameters and extended information, for example, Level 3 codes identify the target device instance number, Level 4 codes identify the operation priority, and Levels 5 and 6 are reserved for future function expansion; a Protocol is adopted. The Buffers serialization protocol implements data serialization. The data structure is divided into a fixed header and a variable data area: the fixed header contains the transaction code (4 bytes), data length (4 bytes), client identifier (8 bytes), and timestamp (8 bytes); the variable data area contains operation parameters or return data, supports nested structures and dynamic arrays, and balances serialization efficiency and compatibility.

[0060] During server initialization, a globally unique service discovery endpoint is registered, and metadata containing service identifier, version, supported IPC types, and endpoint address is published to the currently running operating system to achieve automatic service discovery.

[0061] As can be seen, in this embodiment, by constructing a layered architecture and designing a standardized mechanism, the underlying differences between various operating systems, cross-process communication mechanisms and peripheral hardware are completely shielded. This enables a single peripheral management architecture that can be applied to multiple operating systems adapted to embedded devices, achieves zero-intrusion access for existing clients, and enables dynamic and seamless expansion of new peripheral drivers. At the same time, a unified instruction and data transmission specification is established to ensure the accuracy and efficiency of cross-system communication.

[0062] Step S402: Obtain the peripheral hardware attribute information of the embedded device, the peripheral access request of the multi-process business client in the currently running operating system, and the corresponding client access attribute information through the server.

[0063] Among them, peripheral hardware attribute information is a collection describing the inherent characteristics and configuration parameters of the physical peripherals connected to the embedded device. It is automatically obtained by the server during the system initialization phase by scanning the peripheral bus, or read in real time when the peripheral hot-plug event is triggered. It mainly includes the peripheral device type, device unique identifier, security attribute level, bus number, device address, hardware channel number, driver matching information, and instance configuration information.

[0064] Among them, the peripheral access request is a command carrier initiated by a multi-process business client to a unified peripheral management server to request access to a specific peripheral and perform a specified operation. It is generated by the client according to its own business needs and sent to the server through the cross-process communication mechanism. It mainly includes the identification information of the requesting client, the identification information of the target peripheral, the type of operation to be performed (such as reading data, writing data, configuration parameters, control commands, etc.), and the required parameters for this access.

[0065] Among them, the client access attribute information is a collection describing the identity characteristics, security permissions and business access requirements of multi-process business clients. It is obtained by the server after the client performs identity authentication when it first accesses the server and establishes a persistent file. It mainly includes the client's unique identifier, security level, priority level, data timeliness tolerance, throughput requirements and the range of peripheral types allowed to be accessed.

[0066] Step S403: Based on the peripheral hardware attribute information, the server performs instantiation management on multiple peripherals to determine the target peripheral to which the peripheral access request points. Among them, peripheral instantiation management is the core foundation for the server to achieve global unified control of peripherals. Based on the obtained peripheral hardware attribute information, the server creates a unique logical abstract object for each physical peripheral, transforming the scattered physical peripheral resources into standardized logical resources that can be uniformly scheduled and managed, providing a unified operation unit for subsequent accurate location of target peripherals and execution of multi-dimensional coordinated control operations.

[0067] In this embodiment, the instantiation management also includes an on-demand startup mechanism and automatic resource reclamation: after the device instance is created, it is in a standby state, does not occupy hardware resources, and does not start the internal acquisition thread; when the first client registers a callback through the cross-process communication mechanism, the onFirstClientConnected() protection method is triggered, the internal acquisition thread is started, hardware resources are initialized, sampling parameters are configured, and the device enters the working state; when the last client cancels the callback, the onLastClientDisconnected() protection method is triggered, the acquisition thread is stopped, hardware resources are released, temporary cache is cleared, and the device returns to the standby state; through the connection status monitoring mechanism, the process termination monitoring, heartbeat detection, and connection timeout detection functions provided by the cross-process communication mechanism are used to monitor the client connection status; when a client disconnects abnormally, the registration information of that client is automatically cleaned up to prevent zombie references in the callback list from causing memory leaks.

[0068] For easier understanding, please refer to Figure 5 , Figure 5This is a schematic diagram of a peripheral instantiation management process provided in an embodiment of this application. The step of instantiating and managing multiple peripherals through the server based on the peripheral hardware attribute information to determine the target peripheral to which the peripheral access request points includes the following steps: S501. Determine the device type of the plurality of peripherals based on the peripheral hardware attribute information, wherein the device types of the plurality of peripherals include input devices and output devices; S502. Determine the instance mode corresponding to each type of peripheral according to the device type and number of the multiple peripherals. The instance mode includes singleton mode and multi-instance mode. And, create instances for the multiple peripherals according to the instance mode corresponding to each type of peripheral and the peripheral hardware attribute information to obtain multiple peripheral instances. S503. Parse the peripheral access request and determine the target peripheral instance that matches the peripheral access request among the plurality of peripheral instances; S504. The peripheral corresponding to the target peripheral instance is determined as the target peripheral to which the peripheral access request points.

[0069] Specifically, in step S501, the server automatically identifies and classifies all physical peripherals into two basic categories: input devices and output devices by parsing the device type identifier field in the peripheral hardware attribute information.

[0070] Specifically, in step S502, the server determines the corresponding instantiation operation mode based on the inherent characteristics of the peripheral device type and the actual number of connections: for devices that exist only in the system and cannot be accessed by multiple instances at the same time (such as the main display screen or system speaker), the singleton mode is adopted, and only one shared instance is created globally for all clients to call; for scenarios where multiple independent devices of the same type can exist at the same time (such as multiple temperature sensors or multiple USB input devices), the multi-instance mode is adopted, and an independent logical instance is created for each physical device to ensure that the instance mode matches the physical characteristics of the device and the usage scenario.

[0071] The server builds a type-instance list mapping table, where the key is the device type identifier and the value is a collection of all instances of that type, supporting type location with constant time complexity; it also supports configuration driver initialization, dynamically creating device instances based on hardware configuration files or runtime detection, and uniformly registering them to the device mapping table.

[0072] In one possible embodiment, the step of creating instances for the plurality of peripherals based on the instance mode corresponding to each type of peripheral and the peripheral hardware attribute information to obtain a plurality of peripheral instances includes: if it is determined that a first type of peripheral among the various types of peripherals is in singleton mode, then a peripheral instance is created for the unique peripheral under the first type; if it is determined that a second type of peripheral among the various types of peripherals is in multi-instance mode, then peripheral instances are created for the plurality of peripherals under the second type respectively, and a parameter array is configured for the peripheral instance according to the peripheral hardware attribute information, wherein the parameter array is used to uniquely distinguish different peripheral instances under the same type, and the parameter array includes at least one of peripheral bus number, device address, hardware channel number, and device unique identifier.

[0073] The server creates peripheral instances based on the instance mode of the peripheral: for singleton peripherals, it directly creates a globally unique peripheral instance; for multiple peripherals of the same type (such as multiple temperature sensors of the same model) in multi-instance mode, it creates independent peripheral instances respectively. It extracts peripheral bus number, device address, hardware channel number, device unique identifier and other information from peripheral hardware attribute information and combines them to form a parameter array, thereby realizing the unique identification and accurate differentiation of different peripheral instances of the same type.

[0074] In one possible embodiment, parsing the peripheral access request and determining the target peripheral instance that matches the peripheral access request among the plurality of peripheral instances includes: constructing a peripheral type-instance mapping table based on the device types of the plurality of peripherals and their corresponding peripheral instances, wherein the peripheral type-instance mapping table is used to record the one-to-one correspondence between device types and peripheral instance sets; parsing the peripheral access request to obtain the peripheral type identifier and reference parameter array of the peripheral to be accessed; querying the peripheral type-instance mapping table based on the peripheral type identifier to obtain a set of target peripheral instances that match the peripheral type identifier; and matching the reference parameter array with the parameter arrays of each peripheral instance in the set of target peripheral instances to determine the matching peripheral instance as the target peripheral instance.

[0075] Understandably, by constructing a peripheral type-instance mapping table and combining it with parameter arrays for precise matching, it is possible to quickly locate the target peripheral instance requested by the client in scenarios where multiple instances and multiple types of peripherals coexist, avoid access confusion between peripherals of the same type, and improve the accuracy and addressing efficiency of peripheral access.

[0076] Step S404: Based on the peripheral hardware attribute information, the client access attribute information, and the system status information of the currently adapted operating system, the server performs multi-dimensional control over the current access process of the target peripheral.

[0077] The multi-dimensional control includes permission verification control with execution priority from high to low, access timing scheduling control and hot-plug control, as well as cross-process communication protocol standardization control based on a unified transaction coding system.

[0078] Among them, the standardized management and control of cross-process communication protocols based on a unified transaction coding system refers to the server establishing hierarchical transaction coding rules and a unified data serialization format to standardize peripheral access commands, response messages and interactive data between the client and the server. This shields the differences in message format and command semantics caused by different operating systems and cross-process communication mechanisms, ensuring that peripheral access requests and execution results can be transmitted and parsed accurately and efficiently, and providing stable and reliable communication support for permission verification, timing scheduling and hot-plug management.

[0079] In one possible embodiment, the step of performing multi-dimensional control over the current access process of the multi-process business client to the target peripheral device through the server based on the peripheral hardware attribute information, the client access attribute information, and the system status information of the currently running operating system includes: performing permission verification and control on multiple clients in the multi-process business client based on the client security level and client identifier in the client access attribute information, and the device identifier information and security attribute information in the peripheral hardware attribute information, wherein the permission verification and control includes cross-process communication namespace isolation, peripheral access capability set allocation, access control list configuration, and audit log recording; performing access timing scheduling and control on the peripheral access requests corresponding to clients that pass the permission verification based on the access requirement parameters in the client access attribute information and the load status parameters in the system status information; and performing hot-plug management on the multiple peripheral devices based on the device identifier information and instance configuration information in the peripheral hardware attribute information, and the peripheral bus status and hardware resource status in the system status information.

[0080] The access requirement parameters are parameters in the client's access attribute information that describe the characteristics of this peripheral device access service. These mainly include access frequency, data transmission volume, response latency requirements, exclusive / shared usage requirements, and duration. The server allocates system resources and performs timing scheduling based on these parameters. The client security level is a preset permission level identifier in the client's access attribute information, used to distinguish the peripheral device access priority and operation permissions of different clients, thus implementing hierarchical access control.

[0081] Among them, the load status parameters refer to system operation status indicators such as CPU utilization, memory utilization, peripheral bus bandwidth utilization, and process scheduling queue length collected in real time by the current operating system kernel. These indicators are used to determine whether system resources are sufficient and to provide a basis for time-series scheduling.

[0082] Security attribute information is part of the peripheral hardware attributes and includes security-related configurations such as access permission requirements, data transmission encryption level, and whether cross-client sharing is allowed. These are used to determine whether a client is qualified to access the device. Instance configuration information refers to the configuration content determined when the peripheral instance is created, such as the running mode, parameter array, lifecycle policy, and singleton / multi-instance attributes. This information is used to support the dynamic management and hot-swapping of peripheral instances.

[0083] For easier understanding, please refer to Figure 6 , Figure 6 This is a flowchart illustrating a process for permission verification and control of peripheral access requests provided in an embodiment of this application. The specific steps include: performing permission verification and control on multiple clients in the multi-process business client based on the client security level and client identifier in the client access attribute information, and the device identifier information and security attribute information in the peripheral hardware attribute information. S601. Based on the client security level, create independent cross-process communication namespaces for clients with different security levels, so that the client can only see the peripheral instance service endpoint that matches its security level. S602. Assign a fine-grained set of peripheral access capabilities to the plurality of clients based on the client identifier and the device identifier information; S603. Configure an access control list for each peripheral instance based on the security attribute information and the device identification information; S604. Sequentially verify the cross-process communication namespace permissions, peripheral access capability set permissions, access control list permissions, and audit log permissions of the multiple clients for the target peripheral. After all verifications pass, execute the access operation for the target peripheral and record the client identifier, operation type, operation result, and timestamp to the audit log.

[0084] The peripheral access capability set includes the types of peripherals allowed to be accessed and the types of operations allowed to be performed. The access control list includes the client identifiers allowed to access, the allowed operation types, and the access time window.

[0085] Specifically, in step S601, the server uses the client security level as the isolation dimension to create independent cross-process communication namespaces for clients of different levels, which cannot be accessed by exceeding authority. Each namespace will be pre-bound and only expose the peripheral instance service endpoint that matches the security level. The high-security peripheral services are directly shielded from the process communication domain, and the client access scope is forcibly isolated from the underlying communication mechanism to prevent unauthorized probes and access.

[0086] Specifically, in step S604, a four-level progressive security isolation mechanism is adopted: Level 1, cross-process communication namespace isolation: independent IPC namespaces are created for clients with different security levels, restricting the range of service endpoints they can see, and achieving environment-level security isolation from the underlying communication mechanism; Level 2, peripheral access capability set allocation: fine-grained peripheral access capabilities are allocated to clients, such as "adc:read" and "led:write". The server verifies the client capability set before executing the operation, following the principle of least privilege; Level 3, access control list configuration: ACLs are configured for each peripheral instance, specifying the allowed client identifier, allowed operation type, access time window (e.g., only allowing access during working hours from 8:00 to 18:00), and access frequency limit; Level 4, audit log recording: all peripheral access operations are recorded, including client identifier, operation timestamp, operation type, operation object, operation parameters, and operation result. Log export and query are supported, and an anomaly detection function is built-in. When an abnormal access is detected, an alarm is automatically triggered, realizing post-event security auditing and pre-event deterrence. The server performs strict sequential verification according to namespace permissions, capability set permissions, ACL permissions, and audit logs. Only when all four levels of permissions pass verification will the server allow access to the peripheral device. If any level of verification fails, the request is immediately rejected, thus building a security barrier throughout the entire process. For example, when a client with a security level of 2 requests access to a sensor peripheral device identified as DEV002, the server first verifies that it is in a level 2 communication namespace, then verifies that it has read capability set permissions for the device, and then verifies that it is in DEV002's access control list. If all verifications pass, access is allowed. If the client is in a lower-level namespace or is not in the access control list, the access request is directly blocked.

[0087] As can be seen, in this embodiment, a four-fold security control mechanism is implemented, consisting of hierarchical namespace isolation, fine-grained access capability set allocation, peripheral-level access control list configuration, and audit log recording. Combined with four-level progressive permission verification, this achieves end-to-end security isolation between the client and peripheral devices, from the communication domain to operation permissions and then to device authorization. This effectively avoids unauthorized access, illegal calls, and data leakage, and significantly improves the system security and reliability in scenarios where multiple processes concurrently access peripheral devices.

[0088] For easier understanding, please refer to Figure 7 , Figure 7 This is a flowchart illustrating the access timing scheduling and control of peripheral access requests provided in this application embodiment. The specific steps of scheduling and controlling the access timing of peripheral access requests corresponding to clients that have passed the permission verification, based on access requirement parameters in the client access attribute information and load status parameters in the system status information, include: S701. Based on the access requirement parameters, establish corresponding client capability profiles for one or more clients that have passed the permission verification. The client capability profiles include priority level, data timeliness tolerance, and throughput requirements. S702. Determine the peripheral access response sequence of the one or more clients based on the client capability profile and the preset scheduling policy; S703. Respond to peripheral access requests from high-priority clients according to the peripheral access response sequence. S704. During the response process, when the system load in the load status parameter is detected to exceed a preset threshold, the response time interval corresponding to the low-priority client with higher data timeliness tolerance in the peripheral access response sequence is increased or the transmission of its non-critical data is suspended.

[0089] Specifically, based on information such as access frequency, response latency, data volume, and usage patterns included in the client's access request parameters, the server extracts and generates corresponding priority levels, data timeliness tolerance, and throughput requirements for each client, thereby establishing a unique client capability profile. The priority level identifies the urgency of the client's access to peripherals and the order of resource allocation; the data timeliness tolerance indicates the acceptable range of data latency for the client; and the throughput requirement characterizes the amount of data transmission required by the client in a single instance or per unit of time, thus providing a clear scheduling basis for subsequent concurrent access timing.

[0090] The preset scheduling strategy includes at least one of priority preemption, time slice rotation, and weight allocation. The peripheral access response timing is used to specify the time order, time interval, and single response duration of the server's response to multiple peripheral access requests.

[0091] In one possible embodiment, determining the peripheral access response sequence of the one or more clients based on the client capability profile and a preset scheduling policy includes: initially sorting the peripheral access requests corresponding to the one or more clients according to the priority level and the preset scheduling policy to determine the time order of peripheral access responses; allocating a maximum allowable delay time to each peripheral access request according to the data timeliness tolerance and the preset scheduling policy, adjusting the execution time of the initially sorted requests to determine the time interval between two adjacent peripheral access responses; allocating corresponding bandwidth resources to each peripheral access request according to the throughput requirement and the preset scheduling policy to determine the duration of a single response; and integrating the time order of peripheral access responses, the time interval between two adjacent peripheral access responses, and the duration of a single response to obtain the peripheral access response sequence.

[0092] For example, if the system adopts a preset scheduling strategy that combines priority preemption with weight allocation, in the scenario where three clients access the temperature sensor simultaneously: the server first sorts the high-priority control client (level 3), the medium-priority data acquisition client (level 2), and the low-priority background monitoring client (level 1) according to their priority levels; then, based on their respective data timeliness tolerance, it allocates maximum allowable delays of 50ms, 200ms, and 500ms respectively and adjusts the request execution time points to determine the time interval between two adjacent peripheral access responses; subsequently, according to throughput requirements and the weight allocation strategy, it allocates bus bandwidth in a 6:3:1 ratio to determine the single response duration as 20ms, 15ms, and 5ms respectively; finally, it integrates the time sequence, time interval, and single response duration to form a complete peripheral access response sequence: 0ms to start the control client response for 20ms, 50ms to start the data acquisition client response for 15ms, and 200ms to start the background monitoring client response for 5ms.

[0093] It should be noted that this application only provides an exemplary description of a preset scheduling strategy. In practical applications, other scheduling strategies such as time-slice round-robin, dynamic weight adjustment, and fair sharing can be adopted individually or in combination according to the system scenario. The corresponding peripheral access response timing calculation method can also be flexibly adapted to meet the concurrent access control requirements of different embedded platforms, different peripheral types, and different business scenarios.

[0094] Furthermore, the server executes peripheral access responses in an orderly manner according to the calculated peripheral access response sequence. During the response process, dynamic scheduling is achieved by monitoring system load status parameters in real time. When the system load exceeds a preset threshold, resource adjustment is performed based on the priority and timing tolerance in the client capability profile. Priority is given to ensuring the stable operation of high-priority tasks. By increasing the response time interval for low-priority clients that are not sensitive to data latency, or suspending their non-critical data transmission, system hardware resources are proactively released to avoid bus congestion, response delays, or system anomalies caused by concurrent access overload, thereby achieving stability and efficiency throughout the entire peripheral access process.

[0095] As can be seen, in this embodiment, by establishing client capability profiles, combining multiple scheduling strategies to calculate peripheral access response timing, and dynamically adjusting according to system load during transmission, the real-time performance and reliability of high-priority client peripheral access are guaranteed, while the reasonable allocation and efficient utilization of system resources are achieved, effectively improving system stability and scheduling flexibility when multiple clients access peripherals concurrently.

[0096] For easier understanding, please refer to Figure 8 , Figure 8This is a flowchart illustrating a hot-plug management process for peripherals provided in an embodiment of this application. The specific steps for hot-plug management of the multiple peripherals, based on device identification information and instance configuration information in the peripheral hardware attribute information, and peripheral bus status and hardware resource status in the system status information, include: S801. Preload the drivers corresponding to all supported peripheral types according to the instance configuration information, and initialize the system hardware resource pool, which includes available bus channels, interrupt numbers and memory address space. S802. When a peripheral insertion event is detected, obtain the device identification information of the newly inserted peripheral and match the corresponding preloaded driver; and allocate dedicated hardware resources for the newly inserted peripheral from the system hardware resource pool according to the current hardware resource status; and create a peripheral instance for the newly inserted peripheral according to the instance configuration information, register the peripheral instance service endpoint and update the system peripheral list. S803. When a peripheral device is detected to be unplugged, obtain the device identification information of the latest unplugged peripheral device; and start a delayed removal timer. If the peripheral device recovers its connection within a preset timeout period, maintain the instance state. If it does not recover within the timeout period, destroy the peripheral device instance corresponding to the latest unplugged peripheral device and deregister the corresponding peripheral device instance service endpoint; and reclaim the dedicated hardware resources allocated to the latest unplugged peripheral device; and synchronously update the system peripheral device list and the system hardware resource pool.

[0097] Specifically, in step S801, preloading the drivers corresponding to all supported peripheral types is to avoid response delays and system lag caused by temporarily loading drivers when peripherals are inserted, and to ensure that the driver can be matched and started immediately after insertion. Initializing the system hardware resource pool is because hot-plugging peripherals requires dynamic allocation of dedicated hardware resources (such as bus channels, interrupt numbers, and memory address spaces). By pre-sorting and centrally managing the available hardware resources in the system, resources can be quickly allocated when peripherals are inserted and resources can be promptly reclaimed when peripherals are removed, ensuring efficient use of resources and avoiding conflicts.

[0098] Specifically, in step S802, after a peripheral insertion event is detected, the server first reads the device identification information of the peripheral and completes a precise match with the driver preloaded in S801. Then, based on the real-time hardware resource status, it allocates a dedicated bus channel, interrupt number, and memory address space for the peripheral from the system hardware resource pool to avoid resource conflicts. Subsequently, it creates the corresponding peripheral instance according to the instance configuration information, registers the peripheral instance service endpoint that can be accessed by the client, and synchronously updates the new device information to the system peripheral list, completing the entire process of going online and ready.

[0099] Similarly, in step S803, when a peripheral device is unplugged, the server will destroy the corresponding peripheral device instance and deregister the server endpoint, while reclaiming hardware resources and updating the system list and resource pool.

[0100] The hot-plug management also includes a delayed removal strategy: when a device is detected being unplugged, the instance is not immediately destroyed, but a delayed removal timer is started with a preset timeout of 500ms. During the timeout, the peripheral bus status is continuously monitored. If the device is detected to be reinserted and the device identification information matches, it is determined to be a temporary disconnection (such as poor contact), the timer is stopped, and the instance status is maintained without rebuilding the instance. If the timeout expires and the device is not detected to have recovered, it is determined to be permanently removed, and the instance is destroyed, the server endpoint is deregistered, hardware resources are reclaimed, and the system peripheral list is updated. The preset timeout of 500ms is determined based on the standard recovery time of USB device hot-plugging and the I2C bus reconnection detection cycle, taking into account both the tolerance for poor contact and the timeliness of resource reclamation.

[0101] As can be seen, in this embodiment, by preloading the driver, managing the hardware resources in a unified pool, and automating the entire process of inserting and removing peripherals, a rapid response to hot-swapping of peripherals, conflict-free resource allocation, and safe recycling are achieved, ensuring the stability and continuity of the system when multiple peripherals are dynamically accessed and removed.

[0102] In addition, this application supports the rapid and seamless integration of new peripherals. The standardized process is as follows: define the device interface specification, inherit the basic abstract class to implement the driver class and client class, add device support detection logic, and register instances during service initialization. It also supports dynamic extension of operation codes. New functions can register new operation codes and processing logic through the system interface without modifying the core code.

[0103] As can be seen, in this embodiment, a single unified peripheral management server centrally takes over all peripheral management permissions within the currently running operating system, breaking the traditional fragmented development model where each operating system independently builds its own peripheral management system. This enables a unified peripheral management code to be deployed compatiblely on multiple mainstream operating systems such as Linux, Android, and HarmonyOS, significantly reducing R&D and maintenance costs. At the same time, the unified server integrates peripheral instantiation management and multi-dimensional coordination and control capabilities, fundamentally solving the problems of concurrent peripheral access conflicts from multiple clients, lack of security isolation, and chaotic handling of hot-plug events, thereby improving the operational stability and security of embedded devices.

[0104] The above primarily describes the solutions of the embodiments of this application from the perspective of the method execution process. It is understood that, in order to achieve the above functions, the electronic device includes corresponding hardware structures and / or software modules for executing each function. Those skilled in the art should readily recognize that, in conjunction with the units and algorithm steps of the various examples described in the embodiments provided herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed by hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0105] This application embodiment can divide the electronic device into functional units according to the above method example. For example, each function can be divided into a separate functional unit, or two or more functions can be integrated into one processing unit. The integrated unit can be implemented in hardware or as a software functional unit. It should be noted that the unit division in this application embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.

[0106] When dividing each function into modules according to its corresponding function. Figure 9 This is a functional block diagram of a unified peripheral management device 900 provided in an embodiment of this application. The unified peripheral management device 900 is applied to an embedded device, which is configured with multiple peripheral interfaces. The unified peripheral management device 900 includes a first processing module 910, an acquisition module 920, and a second processing module 930, wherein: The first processing module 910 is used to build a unified peripheral device management server based on a cross-process communication mechanism. The server adopts a dual-process service architecture, including a sensor service process and a hardware component service process, which are respectively responsible for the centralized management of input devices and output devices, and realize fault isolation between input devices and output devices. The acquisition module 920 is used to acquire peripheral hardware attribute information of the embedded device, peripheral access requests of multi-process business clients in the currently running operating system, and corresponding client access attribute information through the server. The second processing module 930 is used to perform instantiation management of multiple peripherals through the server based on the peripheral hardware attribute information, so as to determine the target peripheral to which the peripheral access request points. The instantiation management includes an on-demand startup mechanism, which is used to start the device hardware resources when the first client registers a callback, and to automatically stop the device and release resources when all clients disconnect. Based on the peripheral hardware attribute information, the client access attribute information, and the system status information of the currently running operating system, the server performs multi-dimensional control over the current access process of the multi-process business client to the target peripheral. The multi-dimensional control includes permission verification control with execution priority from high to low, access timing scheduling control and hot-plug control, as well as cross-process communication protocol standardization control based on a unified transaction coding system.

[0107] Optionally, in building a unified peripheral management server based on a cross-process communication mechanism, the first processing module 910 is specifically used for: An operating system abstraction layer is constructed to provide a unified and standardized system call interface, enabling the server to adapt to multiple operating systems; A cross-process communication adaptation layer is constructed to provide a unified service access interface for the multi-process business clients. The cross-process communication adaptation layer supports multiple cross-process communication mechanisms, including D-Bus, Binder, Socket, shared memory, message queue mechanism and RPC framework mechanism. The message queue mechanism includes System V message queue or POSIX message queue, and the RPC framework mechanism includes gRPC or Thrift. A unified core management layer is constructed to integrate peripheral instantiation management, timing scheduling control, permission verification control and hot-plug control functional modules. The unified core management layer adopts the dual-process service architecture. The sensor service process and the hardware component service process run independently of each other. The failure of one process does not affect the normal operation of the other process. Construct a peripheral driver abstraction layer, encapsulate the driver interfaces of different types of peripherals, and provide a unified peripheral access interface; A unified transaction coding system and data serialization format are established. The unified transaction coding system adopts a hierarchical coding strategy, with the first-level code representing the major transaction category, the second-level code representing the transaction sub-category, and the third to sixth-level codes representing specific operation parameters and extended information. The data serialization format is implemented based on the Protocol Buffers serialization protocol. Perform server-side initialization operations to complete the construction of the unified peripheral management server. The initialization operations include registering a globally unique service discovery endpoint and publishing unified peripheral management service metadata to the currently running operating system.

[0108] Optionally, in determining the target peripheral for which the peripheral access request is directed, the second processing module 930 is specifically used to: In the step of instantiating and managing multiple peripherals through the server based on the peripheral hardware attribute information to identify the target peripheral. The device types of the plurality of peripherals are determined based on the peripheral hardware attribute information, and the device types of the plurality of peripherals include input devices and output devices; The instance mode corresponding to each type of peripheral is determined according to the device type and number of the multiple peripherals. The instance mode includes singleton mode and multi-instance mode. Instances are created for the multiple peripherals according to the instance mode corresponding to each type of peripheral and the peripheral hardware attribute information to obtain multiple peripheral instances. Parse the peripheral access request and determine the target peripheral instance that matches the peripheral access request among the plurality of peripheral instances; The peripheral corresponding to the target peripheral instance is determined as the target peripheral to which the peripheral access request points.

[0109] Optionally, in the step of creating instances for the plurality of peripherals according to the instance modes corresponding to each type of peripheral and the peripheral hardware attribute information, to obtain a plurality of peripheral instances, the second processing module 930 is specifically used for: If it is determined that a first type of peripheral is a singleton among the various types of peripherals, then a peripheral instance is created for the unique peripheral under the first type. If it is determined that there is a second type of peripheral in the multi-instance mode among the various types of peripherals, then peripheral instances are created for the multiple peripherals under the second type, and a parameter array is configured for the peripheral instance according to the peripheral hardware attribute information. The parameter array is used to uniquely distinguish different peripheral instances under the same type. The parameter array includes at least one of peripheral bus number, device address, hardware channel number, and device unique identifier.

[0110] Optionally, in the aspect of performing multi-dimensional control over the current access process of the multi-process business client to the target peripheral device based on the peripheral hardware attribute information, the client access attribute information, and the system status information of the currently running operating system, the second processing module 930 is specifically used for: Based on the client security level and client identifier in the client access attribute information, and the device identifier and security attribute information in the peripheral hardware attribute information, permission verification and control are performed on multiple clients in the multi-process business client. The permission verification and control includes cross-process communication namespace isolation, peripheral access capability set allocation, access control list configuration and audit log recording. Based on the access requirement parameters in the client access attribute information and the load status parameters in the system status information, access timing scheduling and control are performed on the peripheral device access requests corresponding to the client that has passed the permission verification. Based on the device identification information and instance configuration information in the peripheral hardware attribute information, and the peripheral bus status and hardware resource status in the system status information, hot-plug management is performed on the multiple peripherals.

[0111] Optionally, in terms of performing permission verification and control on multiple clients in the multi-process business client based on the client security level and client identifier in the client access attribute information, and the device identifier information and security attribute information in the peripheral hardware attribute information, the second processing module 930 is specifically used for: Based on the client's security level, create independent cross-process communication namespaces for clients with different security levels, so that the client can only see the peripheral instance service endpoint that matches its security level; Based on the client identifier and the device identifier information, a fine-grained set of peripheral access capabilities is assigned to the plurality of clients. The set of peripheral access capabilities includes the types of peripherals that are allowed to be accessed and the types of operations that are allowed to be performed. Configure an access control list for each peripheral instance based on the security attribute information and the device identification information. The access control list includes the client identifiers allowed to access, the allowed operation types, and the access time window. The system sequentially verifies the cross-process communication namespace permissions, peripheral access capability set permissions, access control list permissions, and audit log permissions of the multiple clients for the target peripheral. After all verifications pass, the system executes the access operation for the target peripheral and records the client identifier, operation type, operation result, and timestamp in the audit log.

[0112] Optionally, in the aspect of managing the access timing of peripheral access requests corresponding to clients that have passed the permission verification based on the access request parameters in the client access attribute information and the load status parameters in the system status information, the second processing module 930 is specifically used for: Based on the access requirement parameters, a corresponding client capability profile is established for one or more clients that pass the permission verification. The client capability profile includes priority level, data timeliness tolerance, and throughput requirements. The peripheral access response sequence of the one or more clients is determined based on the client capability profile and the preset scheduling strategy. The preset scheduling strategy includes at least one of priority preemption, time slice rotation, and weight allocation. The peripheral access response sequence is used to specify the time order, time interval, and single response duration of the server in response to multiple peripheral access requests. According to the peripheral access response sequence, the peripheral access requests of the higher priority clients are responded to first; During the response process, when the system load in the load status parameter is detected to exceed a preset threshold, the response time interval corresponding to the low-priority client with a higher tolerance for data timeliness in the peripheral access response sequence is increased or the transmission of its non-critical data is suspended.

[0113] Optionally, in determining the peripheral access response timing of the one or more clients based on the client capability profile and preset scheduling policy, the second processing module 930 is specifically used for: Based on the priority level and the preset scheduling strategy, the peripheral access requests corresponding to one or more clients are initially sorted to determine the time order of peripheral access responses. Based on the data timeliness tolerance and the preset scheduling strategy, a maximum allowable delay time is allocated to each peripheral access request, and the execution time of the initially sorted requests is adjusted to determine the time interval between two adjacent peripheral access responses. Based on the throughput requirements and the preset scheduling strategy, allocate corresponding bandwidth resources for each peripheral access request and determine the single response duration. The peripheral access response time sequence is obtained by integrating the time sequence of the peripheral access responses, the time interval between two adjacent peripheral access responses, and the duration of a single response.

[0114] Optionally, in the step of hot-plugging and managing the multiple peripherals based on the device identification information and instance configuration information in the peripheral hardware attribute information, and the peripheral bus status and hardware resource status in the system status information, the second processing module 930 is specifically used for: Based on the instance configuration information, preload the drivers corresponding to all supported peripheral types, and initialize the system hardware resource pool, which includes available bus channels, interrupt numbers, and memory address space. When a peripheral insertion event is detected, the device identification information of the newly inserted peripheral is obtained and the corresponding preloaded driver is matched; and, according to the current hardware resource status, dedicated hardware resources are allocated to the newly inserted peripheral from the system hardware resource pool; and, according to the instance configuration information, a peripheral instance is created for the newly inserted peripheral, the peripheral instance service endpoint is registered and the system peripheral list is updated. When a peripheral device is detected being unplugged, the system obtains the device identification information of the latest unplugged peripheral device; starts a delayed removal timer, and if the peripheral device recovers its connection within a preset timeout period, the instance status is maintained; if it does not recover within the timeout period, the peripheral device instance corresponding to the latest unplugged peripheral device is destroyed and the corresponding peripheral device instance service endpoint is deregistered; the dedicated hardware resources allocated to the latest unplugged peripheral device are reclaimed; and the system peripheral device list and the system hardware resource pool are updated synchronously.

[0115] It is evident that by building a unified peripheral management server based on the cross-process communication mechanism, the server can uniformly take over the management permissions of all peripherals within the currently running operating system, centrally receive peripheral access requests from multi-process business clients, and perform global unified instantiation management and multi-dimensional coordination and control of all peripheral resources. This enables global sharing and orderly and secure access to peripheral resources, significantly improving hardware resource utilization, system stability, and security.

[0116] It should be noted that the specific implementation of each operation can be described in the corresponding description of the method embodiments shown above. The unified peripheral management device 900 can be used to execute the method embodiments of this application, and will not be described again here.

[0117] This application also provides a computer-readable storage medium storing a computer program for electronic data interchange, which causes a computer to perform some or all of the steps of any of the methods described in the above method embodiments, wherein the computer includes an electronic device.

[0118] This application also provides a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program operable to cause a computer to perform some or all of the steps of any of the methods described in the above method embodiments. The computer program product may be a software installation package, and the computer may include an electronic device.

[0119] It should be noted that, for the sake of simplicity, the above embodiments are all described as a series of actions. Those skilled in the art should understand that this application is not limited to the described order of actions, as some steps in the embodiments of this application can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions, steps, modules, or units involved are not necessarily essential to the embodiments of this application.

[0120] In the above embodiments, the descriptions of each embodiment in this application have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0121] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM or random access memory (RAM), magnetic disks, or optical disks.

[0122] The steps of the methods or algorithms described in the embodiments of this application can be implemented in hardware or by a processor executing software instructions. The software instructions can consist of corresponding software modules, which can be stored in RAM, flash memory, ROM, EPROM, electrically erasable programmable read-only memory (EEPROM), registers, hard disk, portable hard disk, read-only optical disk (CD-ROM), or any other form of storage medium well known in the art. An exemplary storage medium is coupled to a processor, enabling the processor to read information from and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and storage medium can reside in an ASIC. Furthermore, the ASIC can reside in a terminal device or management device. Alternatively, the processor and storage medium can exist as discrete components in the terminal device or management device.

[0123] Those skilled in the art will recognize that, in one or more of the examples above, the functions described in the embodiments of this application can be implemented, in whole or in part, by software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. This computer program product includes one or more computer instructions. When these computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., digital video discs (DVDs)), or semiconductor media (e.g., solid-state disks (SSDs)).

[0124] The modules / units included in the various devices and products described in the above embodiments can be software modules / units, hardware modules / units, or a combination of both. For example, for devices and products applied to or integrated into a chip, all modules / units can be implemented using hardware methods such as circuits, or at least some modules / units can be implemented using software programs that run on a processor integrated within the chip, while the remaining (if any) modules / units can be implemented using hardware methods such as circuits. For devices and products applied to or integrated into a chip module, all modules / units can be implemented using hardware methods such as circuits. Different modules / units can be located in the same component (e.g., chip, circuit module, etc.) or different components of the chip module, or at least some modules / units can be implemented using hardware methods such as circuits. The implementation is achieved through a software program that runs on the processor integrated within the chip module. The remaining modules / units (if any) can be implemented using hardware methods such as circuits. For various devices and products applied to or integrated into terminal equipment, each of their modules / units can be implemented using hardware methods such as circuits. Different modules / units can be located in the same component (e.g., chip, circuit module, etc.) or different components within the terminal equipment. Alternatively, at least some modules / units can be implemented through a software program that runs on the processor integrated within the terminal equipment, while the remaining modules / units (if any) can be implemented using hardware methods such as circuits.

[0125] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the embodiments of this application. It should be understood that the above descriptions are merely specific embodiments of the embodiments of this application and are not intended to limit the protection scope of the embodiments of this application. Any modifications, equivalent substitutions, improvements, etc., made on the basis of the technical solutions of the embodiments of this application should be included within the protection scope of the embodiments of this application.

Claims

1. A unified peripheral management method, characterized by, Applied to an embedded device configured with multiple peripheral interfaces, the method includes: A unified peripheral device management server is built based on a cross-process communication mechanism. The server adopts a dual-process service architecture, including a sensor service process and a hardware component service process, which are respectively responsible for the centralized management of input devices and output devices, and realize fault isolation between input devices and output devices. The server obtains peripheral hardware attribute information of the embedded device, peripheral access requests of multi-process business clients in the currently running operating system, and corresponding client access attribute information. Based on the peripheral hardware attribute information, the server performs instantiation management on multiple peripherals to determine the target peripheral to which the peripheral access request points. The instantiation management includes an on-demand startup mechanism, which is used to start the device hardware resources when the first client registers a callback, and to automatically stop the device and release resources when all clients disconnect. Based on the peripheral hardware attribute information, the client access attribute information, and the system status information of the currently running operating system, the server performs multi-dimensional control over the current access process of the multi-process business client to the target peripheral. This multi-dimensional control includes permission verification control with execution priority from high to low, access timing scheduling control, and hot-plug control, as well as standardized control based on a unified transaction coding system for cross-process communication protocols. The unified peripheral management server built based on the cross-process communication mechanism includes: An operating system abstraction layer is constructed to provide a unified and standardized system call interface, enabling the server to adapt to multiple operating systems; A cross-process communication adaptation layer is constructed to provide a unified service access interface for the multi-process business clients. The cross-process communication adaptation layer supports multiple cross-process communication mechanisms, including D-Bus, Binder, Socket, shared memory, message queue mechanism and RPC framework mechanism. The message queue mechanism includes System V message queue or POSIX message queue, and the RPC framework mechanism includes gRPC or Thrift. A unified core management layer is constructed to integrate peripheral instantiation management, timing scheduling control, permission verification control and hot-plug control functional modules. The unified core management layer adopts the dual-process service architecture. The sensor service process and the hardware component service process run independently of each other. The failure of one process does not affect the normal operation of the other process. Construct a peripheral driver abstraction layer, encapsulate the driver interfaces of different types of peripherals, and provide a unified peripheral access interface; A unified transaction coding system and data serialization format are established. The unified transaction coding system adopts a hierarchical coding strategy, with the first-level code representing the major transaction category, the second-level code representing the transaction sub-category, and the third to sixth-level codes representing specific operation parameters and extended information. The data serialization format is implemented based on the Protocol Buffers serialization protocol. Perform server initialization operations to complete the construction of the unified peripheral management server. The initialization operations include registering a globally unique service discovery endpoint and publishing unified peripheral management service metadata to the currently running operating system.

2. The method of claim 1, wherein, The step of instantiating and managing multiple peripherals through the server based on the peripheral hardware attribute information to determine the target peripheral to which the peripheral access request points includes: The device types of the plurality of peripherals are determined based on the peripheral hardware attribute information, and the device types of the plurality of peripherals include input devices and output devices; The instance mode corresponding to each type of peripheral is determined according to the device type and the number of devices of the multiple peripherals. The instance mode includes singleton mode and multi-instance mode. Instances are created for the multiple peripherals according to the instance mode corresponding to each type of peripheral and the peripheral hardware attribute information to obtain multiple peripheral instances. Parse the peripheral access request and determine the target peripheral instance that matches the peripheral access request among the plurality of peripheral instances; The peripheral corresponding to the target peripheral instance is determined as the target peripheral to which the peripheral access request points.

3. The method of claim 2, wherein, The step of creating instances for the multiple peripherals based on the instance modes corresponding to each type of peripheral and the peripheral hardware attribute information, resulting in multiple peripheral instances, includes: If it is determined that a first type of peripheral is a singleton among the various types of peripherals, then a peripheral instance is created for the unique peripheral under the first type. If it is determined that there is a second type of peripheral in the multi-instance mode among the various types of peripherals, then peripheral instances are created for the multiple peripherals under the second type, and a parameter array is configured for the peripheral instance according to the peripheral hardware attribute information. The parameter array is used to uniquely distinguish different peripheral instances under the same type. The parameter array includes at least one of peripheral bus number, device address, hardware channel number, and device unique identifier.

4. The method according to any one of claims 1 to 3, characterized in that, The step of performing multi-dimensional control over the current access process of the multi-process business client to the target peripheral device based on the peripheral device hardware attribute information, the client access attribute information, and the system status information of the currently running operating system, through the server, includes: Based on the client security level and client identifier in the client access attribute information, and the device identifier and security attribute information in the peripheral hardware attribute information, permission verification and control are performed on multiple clients in the multi-process business client. The permission verification and control includes cross-process communication namespace isolation, peripheral access capability set allocation, access control list configuration and audit log recording. Based on the access requirement parameters in the client access attribute information and the load status parameters in the system status information, access timing scheduling and control are performed on the peripheral device access requests corresponding to the client that has passed the permission verification. Based on the device identification information and instance configuration information in the peripheral hardware attribute information, and the peripheral bus status and hardware resource status in the system status information, hot-plug management is performed on the multiple peripherals.

5. The method of claim 4, wherein, The step of performing permission verification and control on multiple clients in the multi-process service client based on the client security level and client identifier in the client access attribute information, and the device identifier information and security attribute information in the peripheral hardware attribute information, includes: Based on the client's security level, create independent cross-process communication namespaces for clients with different security levels, so that the client can only see the peripheral instance service endpoint that matches its security level; Based on the client identifier and the device identifier information, a fine-grained set of peripheral access capabilities is assigned to the plurality of clients. The set of peripheral access capabilities includes the types of peripherals that are allowed to be accessed and the types of operations that are allowed to be performed. Configure an access control list for each peripheral instance based on the security attribute information and the device identification information. The access control list includes the client identifiers allowed to access, the allowed operation types, and the access time window. The system sequentially verifies the cross-process communication namespace permissions, peripheral access capability set permissions, access control list permissions, and audit log permissions of the multiple clients for the target peripheral. After all verifications pass, the system executes the access operation for the target peripheral and records the client identifier, operation type, operation result, and timestamp in the audit log.

6. The method of claim 4, wherein, The step of managing the access timing of peripheral access requests from clients that have passed the permission verification, based on the access request parameters in the client access attribute information and the load status parameters in the system status information, includes: Based on the access requirement parameters, a corresponding client capability profile is established for one or more clients that pass the permission verification. The client capability profile includes priority level, data timeliness tolerance, and throughput requirements. The peripheral access response sequence of the one or more clients is determined based on the client capability profile and the preset scheduling strategy. The preset scheduling strategy includes at least one of priority preemption, time slice rotation, and weight allocation. The peripheral access response sequence is used to specify the time order, time interval, and single response duration of the server in response to multiple peripheral access requests. According to the peripheral access response sequence, the peripheral access requests of the higher priority clients are responded to first; During the response process, when the system load in the load status parameter is detected to exceed a preset threshold, the response time interval corresponding to the low-priority client with a higher tolerance for data timeliness in the peripheral access response sequence is increased or the transmission of its non-critical data is suspended.

7. The method of claim 6, wherein, The step of determining the peripheral access response sequence of the one or more clients based on the client capability profile and preset scheduling policy includes: Based on the priority level and the preset scheduling strategy, the peripheral access requests corresponding to one or more clients are initially sorted to determine the time order of peripheral access responses. Based on the data timeliness tolerance and the preset scheduling strategy, a maximum allowable delay time is allocated to each peripheral access request, and the execution time of the initially sorted requests is adjusted to determine the time interval between two adjacent peripheral access responses. Based on the throughput requirements and the preset scheduling strategy, allocate corresponding bandwidth resources for each peripheral access request and determine the single response duration. The peripheral access response time sequence is obtained by integrating the time sequence of the peripheral access responses, the time interval between two adjacent peripheral access responses, and the duration of a single response.

8. The method of claim 4, wherein, The hot-plug management of the multiple peripherals based on the device identification information and instance configuration information in the peripheral hardware attribute information, and the peripheral bus status and hardware resource status in the system status information, includes: Based on the instance configuration information, preload the drivers corresponding to all supported peripheral types, and initialize the system hardware resource pool, which includes available bus channels, interrupt numbers, and memory address space. When a peripheral insertion event is detected, the device identification information of the newly inserted peripheral is obtained and the corresponding preloaded driver is matched; and, according to the current hardware resource status, dedicated hardware resources are allocated to the newly inserted peripheral from the system hardware resource pool; and, according to the instance configuration information, a peripheral instance is created for the newly inserted peripheral, the peripheral instance service endpoint is registered and the system peripheral list is updated. When a peripheral device is detected being unplugged, the system obtains the device identification information of the latest unplugged peripheral device; starts a delayed removal timer, and if the peripheral device recovers its connection within a preset timeout period, the instance status is maintained; if it does not recover within the timeout period, the peripheral device instance corresponding to the latest unplugged peripheral device is destroyed and the corresponding peripheral device instance service endpoint is deregistered; the dedicated hardware resources allocated to the latest unplugged peripheral device are reclaimed; and the system peripheral device list and the system hardware resource pool are updated synchronously.

9. An embedded device, characterized by Including memory and processor; The memory is used to store programs; The processor is used to execute the program to implement the various steps of the unified peripheral management method as described in any one of claims 1-8.

Images