A mobile police terminal resource atomization and dynamic scheduling method

Abstract

The application discloses a kind of mobile police terminal resource atomization and dynamic scheduling method, by reconstructing terminal layered architecture, with the aid of hardware abstraction layer and service service split, realize software and hardware deep decoupling, reduce the difficulty of adaptation, improve the robustness of architecture;By building layered standardization interface system, encapsulate interface to hardware capability, service service layer by layer, and realize multi-protocol, multi-version interface compatibility through normalization scheduling interface, unified call format, parameter specification and constraint rule, can greatly reduce the implementation cost, reduce repeated development work;Rely on atomic resource pool to complete the unified registration, indexing and centralized management of all atomic units, supporting atomic resource addressing, load balancing and failover mechanism, resource intelligent allocation and state monitoring can be realized, the mode of traditional resource dispersed management is changed, and resource utilization is improved;Establish the access control architecture of system-level resource call, realize the security check of multiple layers.

Description

Technical Field

[0001] This invention relates to the field of terminal data security technology, specifically to a method for atomizing and dynamically scheduling resources of mobile police terminals. Background Technology

[0002] The smartphone-type mobile police terminal is a dedicated smart terminal device customized for mobile police business scenarios, designed according to the industry standard specifications GA / T 1466.1 / 2 / 3. Based on the general smartphone hardware architecture and intelligent operating system, it undergoes security enhancement modifications and business function adaptations specifically for police use, forming a front-end police device that can compliantly access a dedicated mobile information network. As the core front-end carrier of the mobile police system, this terminal overcomes the limitations of traditional police terminals, such as single functionality and insufficient scalability. It possesses full-process business capabilities for real-time collection, encrypted transmission, intelligent processing, and visualization of police data. It strictly adheres to dedicated mobile network access specifications, relying on dedicated APN and VPDN wireless transmission links to achieve closed-loop operation of police business within a dedicated network.

[0003] From a technical architecture perspective, the mobile policing terminal possesses core technical attributes of standardization, high security, and controllability, constructing an integrated technical system that is hardware-trusted, software-controllable, and environment-adaptable. The terminal is equipped with a hardware-level trusted root security module, serving as the trusted foundation for device cryptographic operations and key management. It is also equipped with dedicated security monitoring components, enabling comprehensive security control including terminal status collection, security policy execution, abnormal event monitoring, and dynamic reporting. Simultaneously, it adopts a multi-mode isolated operation architecture, establishing independent dual-environment carrying modes to achieve secure isolation between policing operations and general applications. In terms of hardware adaptation, the terminal integrates policing-specific hardware modules such as multi-mode communication, high-precision positioning, and intelligent sensing, and meets environmental adaptability requirements such as waterproofing, dustproofing, drop resistance, and wide-temperature operation in complex scenarios. It is also equipped with software security mechanisms such as secure boot, firmware encryption, access control, and remote maintenance, comprehensively ensuring the stability and security of terminal operation.

[0004] Current mainstream mobile policing terminals suffer from inherent drawbacks in their hardware and software architecture and resource utilization, including deep coupling, rigid capabilities, and inflexible scheduling. These shortcomings make them ill-suited to the future needs of smart policing terminals for cross-device interconnection, capability resource sharing, and dynamic, lightweight, and customized business development. Currently, the hardware capabilities of policing terminals are highly bound to the underlying system and business software, preventing sufficient decoupling of hardware and software resources. The lack of standardized capability abstraction and unified calling interfaces means that fundamental capabilities such as underlying hardware computing power, sensing modules, and security modules cannot be abstracted into general atomic interfaces for upper-layer business to call on demand. This significantly limits the reusability and flexible expansion capabilities of policing terminal resources. The main shortcomings are: 1. Existing police applications utilize a full-level, layer-by-layer call model for hardware resources. Each application's call to hardware capabilities requires traversing the operating system application layer, framework layer, system service layer, and driver kernel layer from top to bottom to complete the command interaction. This results in a lengthy call chain and high interaction overhead. When multiple police applications run concurrently on the same terminal, it is highly susceptible to problems such as multiple services competing for underlying hardware resources and repeatedly initiating layer-by-layer calls. This leads to serious waste phenomena such as system resource competition, redundant consumption of computing power, and repeated occupation of hardware resources, resulting in high overall terminal power consumption and low resource utilization.

[0005] 2. The existing hardware and software architecture of police terminals lacks the capabilities for dynamic disassembly, free reconfiguration, and flexible service interface. The underlying hardware capabilities and upper-layer business services are fixed and rigidly combined, failing to achieve dynamic matching and adaptive adaptation of hardware and software capabilities according to differentiated police scenarios. Public security operations encompass various differentiated scenarios, including routine patrols, daily policing, emergency response, and high-level security. Different scenarios have vastly different requirements for the combination of terminal computing power, sensing, communication, and security capabilities. The rigid hardware and software combination model cannot adapt to the flexible and varied scenario requirements of police operations, resulting in extremely poor scenario adaptability and practical suitability.

[0006] 3. Currently, police terminals lack atomic dynamic scheduling and reconfiguration mechanisms, making it impossible to break down hardware and software resources into fine-grained atomic units. This hinders lightweight atomic calls and on-demand reuse by upper-layer applications, and prevents the dynamic trimming of redundant resources and reorganization of core capabilities based on scenario levels. In routine duty scenarios, redundant resources continuously consume system overhead, while in emergency response scenarios, core resources cannot be prioritized, further exacerbating resource waste and business response latency issues. This makes it difficult to meet the low-latency, high-reliability, and highly adaptable requirements of police operations.

[0007] In summary, existing mobile policing terminals suffer from a series of technical shortcomings, including high hardware-software coupling, lack of a unified abstract interface, inability to dynamically reconfigure capabilities, redundant hierarchical calls, wasteful resource competition, and rigid scenario adaptation. The industry has yet to develop an integrated technical solution for hardware-software decoupling, atomized abstraction, and dynamic reconfiguration for policing hierarchical scenarios, leaving a clear technological gap. There is an urgent need for an innovative technical solution that can achieve atomized dynamic reconfiguration of policing hardware and software to address these pain points. Summary of the Invention

[0008] To address the shortcomings of existing technologies, this invention aims to provide a method for atomizing and dynamically scheduling resources in mobile police terminals.

[0009] To achieve the above objectives, the present invention adopts the following technical solution: A method for atomizing and dynamically scheduling resources in a mobile police terminal, characterized by including an atomic resource capability encapsulation stage and a service invocation and system resource scheduling stage; The atomic resource capability encapsulation stage specifically includes the following steps: A1. Hardware Resource Decoupling and Abstraction: Through a hardware abstraction layer and a unified device model, the direct binding between the underlying hardware and upper-layer business applications in the mobile police terminal is removed; by defining a standardized hardware access interface layer, the differences in hardware interfaces, driver versions and register operations of different models of mobile police terminals are shielded, and a unified resource abstraction model independent of hardware is constructed. A2. Atomized decomposition of hardware resources: Hardware atomic units are broken down by function, and each hardware atomic unit has its resource status and capability interface maintained independently by the atomic resource scheduling module of the operating system. A3. Encapsulating system-level atomic capability interfaces: This includes the following steps: (31) Abstract and adapt the driver layer operations, and define a unified set of calling parameters, return formats, error codes and control instructions; (32) Provide hardware atomic capability interfaces for each hardware atomic unit, and encapsulate the hardware atomic capability interfaces provided for each hardware atomic unit into the kernel mode and system service layer to avoid direct access to the underlying hardware by the user mode; A4. Atomized Disassembly of Pre-installed System Software: The independently pre-installed police business applications are split into independent business service modules according to their functions; through dependency injection and interface decoupling, hard-coded dependencies and direct resource consumption are separated, as well as the coupling between business logic and underlying hardware resources are separated. A5. Extract the atomic units of business functions; including: (51) Extract the single sign-on atom from the identity authentication function service and encapsulate cross-application single sign-on and identity ticket verification capabilities; (52) Extract feature comparison atoms from data processing services and encapsulate feature extraction and comparison matching algorithms; (53) Extract AI agent atoms from intelligent analysis services and encapsulate multimodal reasoning, rule engine and decision analysis capabilities; Each business function atomic unit maintains only a single business function atomic service interface, and has an independent call entry point and status management; A6. Encapsulate system-level atomic service interfaces; system-level atomic service interfaces provide multiple calling methods for business function atomic service interfaces, and define interface permission levels, call frequency thresholds, data format specifications, and error handling mechanisms; system-level atomic service interfaces realize dynamic addressing of business function atomic services through service registration and discovery mechanisms; system-level atomic service interfaces encapsulate underlying protocol interaction logic; A7. Construct a normalized interface for atomic resource scheduling; the normalized interface for atomic resource scheduling adopts a unified message queue and protocol adaptation layer, which is compatible with different calling protocols of hardware atomic capability interfaces and business function atomic service interfaces. By defining standardized atomic call request and response message formats, and encapsulating protocol conversion, parameter adaptation and format verification logic, it achieves compatibility of different types and versions of hardware atomic capability interfaces and business function atomic service interfaces. A8. The atomic resource pool has completed unified registration, including: (A81) Enter metadata for each hardware atomic unit and business function atomic unit, including atomic ID, atomic type, capability description, resource capacity, call constraints, security level and status information; (A82) Construct an atomic resource catalog service to support fast retrieval by atomic type, capability tag, and security level; The business invocation and system resource scheduling phase includes the following steps: B1. The business application initiates an atomic call request; the atomic call request message carries the business scenario identifier, target atomic unit ID, call context parameters, application identity credentials and request priority; the business application sends the atomic call request to the atomic resource scheduling normalization interface of the atomic resource scheduling module, while also carrying session context information; B2. The atomic resource scheduling normalization interface performs abnormal behavior pre-checks on atomic call requests; B3. The atomic resource scheduling normalization interface implements secure message encapsulation for atomic call requests that pass the pre-check: embedding the device ID, dynamic session token, current timestamp, and password-secure random number into the atomic call request message; wherein the dynamic session token contains the application identity, permission level, and session validity period; B4. The atomic resource scheduling module performs anti-replay and anti-forgery self-verification on the encapsulated security messages; B5. The atomic resource scheduling module calls the trusted verification interface of the kernel layer trusted function component to perform kernel trusted authentication and dynamic permission verification on the security message that has passed the verification in step B4; after the verification is passed, the atomic resource scheduling module allocates atomic units to the business application according to the request priority and atomic resource load. B6. Business applications call the allocated atomic units to execute business tasks, and at the same time, the monitoring module collects the running status and task progress of the atomic units in real time. B7. Update the atomic resource status and release the resources.

[0010] Furthermore, in step A2, general computing and AI inference acceleration resources are encapsulated as independent computing power atomic units into a computing power atomic set; audio and video acquisition, positioning and environmental perception peripherals are encapsulated as independent perception atomic units into a perception atomic set; and the national cryptographic algorithm engine, secure storage, trusted root and TEE environment are encapsulated as independent security atomic units into a security atomic set.

[0011] Furthermore, in step B2, the atomic resource scheduling normalization interface, based on the exception rule base, performs real-time analysis of atomic call request messages, call frequency, and application identity through the rule engine; if an exception rule is matched, the request is directly intercepted, and a security alarm log containing the request source, exception type, and timestamp is generated, and the process terminates.

[0012] Furthermore, the specific process of step B4 is as follows: (B41) Verify whether the timestamp is within the preset time window to prevent timeout replay attacks; (B42) Verify that the random number is unique in the global request cache to prevent duplicate requests; (B43) Verify message integrity through message digest verification to prevent message tampering; If any of the above checks fail, the request is intercepted and a security alert log is generated, and the process terminates.

[0013] Furthermore, in step B5, the specific verification process is as follows: First, the device ID and dynamic token are verified using a kernel-mode whitelist to confirm their legitimacy, including the issuing authority, validity period, and integrity of the token. Then, based on the business permission mapping table, the permission level of the application identity is checked to see if it matches the access control list of the target atomic resource. If the identity is invalid or the permissions are non-compliant, the request is intercepted and a security alarm log is generated, and the process terminates.

[0014] Furthermore, the specific process of step B7 is as follows: After the business task is completed, the atomic unit is marked as idle, the occupied system resources are released, and the task context data is cleared; the running log and task result metadata of the atomic unit are written to the atomic resource pool; the state of the atomic unit is updated to the global resource directory through the state synchronization mechanism, so that it returns to the atomic resource pool and waits for the next scheduling call; the temporary token and cached data of this session are cleared.

[0015] Furthermore, after the atomic resource capability encapsulation stage, there is also a process of initializing and pre-deploying atomic resources and scheduling rules for mobile police terminals: after the mobile police terminal is powered on and completes system initialization, each hardware atomic unit and business function atomic unit is uniformly registered and filed, and inherent attribute parameters such as power consumption level, business affiliation label, scene adaptation permission and scheduling priority are fixed for all hardware atomic units and business function atomic units. At the same time, a mapping rule library containing scene level and atomic resource adaptation whitelist is constructed.

[0016] Furthermore, in step B5, the specific process by which the atomic resource scheduling module allocates atomic units to the business application based on request priority and atomic resource load is as follows: C1. Current time-series business scenario feature value collection and standardization normalization processing: The business application triggers the call to the atomic unit at time t, collects the business scenario feature value at time t, and performs normalization feature processing; The business scenario feature values ​​include: X1(t) is the alarm level feature; X2(t) is the task type feature; X3(t) is the terminal computing power load feature; X4(t) is the network transmission quality feature; X5(t) is the environmental security attribute feature; X6(t) is the resource trust status feature; The formula for normalized feature processing is as follows: ; In the formula, x i ( t ) represents the normalized feature value corresponding to the i-th dimension of the business scenario feature; X i,min , X i,max They are respectively X i ( t The preset maximum and preset minimum values; C2. Multi-dimensional feature weighted fusion, calculate the instantaneous scene comprehensive score according to the following formula. S ( t ): ; w i The weights corresponding to the i-th dimension of the business scenario features; C3. Exponential smoothing and de-jitter filtering to generate a steady-state scene score S*(t): ; Where S*(t-1) is the steady-state scene score of the previous moment; the operating system initializes the first frame without historical data, so the steady-state scene score of the first frame is equal to the instantaneous comprehensive score by default; C4. Dual threshold quantization judgment, outputting a three-level police scenario rating; based on steady-state scenario scoring. S* ( t According to the preset threshold T 1 and T 2. Obtain scene level results L ( t ): ; C5. Based on the scenario level results obtained in step C4, allocate atomic unit resources to the current business application using the corresponding scheduling mechanism.

[0017] Furthermore, the specific process of step C5 is as follows: If the calculation in step C4 yields L ( t )=1, corresponding to the atomic unit scheduling request in a normal duty scenario, according to priority P j (t) Allocates the atomic unit resources explicitly required for the current call request, without actively releasing other allocated low-priority scheduling resources. When atomic resources are insufficient to complete the allocation, unnecessary background processes or idle atomic units are manually released until the minimum resources required for the current business call are met; If the calculation in step C4 yields L ( t The atomic unit scheduling request corresponding to a general alarm scenario is 2. Only atomic resources required for the current business call and necessary background services are retained. Unnecessary background redundant processes and idle atomic units are scheduled according to priority P. j (t) From low to high, resources are automatically released according to the resource utilization rate to ensure the allocation of computing power and storage for the current business, while reserving the operating resources for the basic daily duties of the mobile police terminal. If the calculation in step C4 yields L ( t When )=3, corresponding to atomic unit scheduling requests in critical emergency scenarios, a kernel-level resource preemption and isolation mechanism is initiated; the current atomic unit calling process list is traversed, and all low-priority (P) processes are prioritized. j (t)<P th The scheduling process and background redundant resources are forcibly released using the `free` function. j This business call exclusively occupies the current atomic unit resource; P j (t) represents the priority of the j-th scheduling process at time t, where j is the process number used to distinguish different scheduling processes; t is the current time point; P th It is the priority threshold.

[0018] The beneficial effects of this invention are as follows: 1. This invention reconstructs the terminal's layered architecture, achieving deep decoupling of software and hardware through the decomposition of hardware abstraction layers and business services. The underlying hardware is divided into three categories of hardware atoms: computing power, sensing, and security. Business capabilities are further decomposed into business function atoms such as single sign-on, feature comparison, and AI intelligent agents. These atomic units are independent of each other, effectively shielding the hardware differences between different mobile policing terminals, reducing adaptation difficulty, and ensuring that upgrades or failures of a single module do not affect overall operation, thus improving architectural robustness.

[0019] 2. This invention establishes a layered, standardized interface system, encapsulating hardware capabilities and business services layer by layer. It achieves compatibility with multiple protocols and versions through a normalized scheduling interface, unifying the calling format, parameter specifications, and constraint rules. Upper-layer business processes do not need to be aware of the underlying implementation, significantly reducing implementation costs. Interfaces can be reused across modules, reducing redundant development work.

[0020] 3. This invention relies on an atomic resource pool to complete the unified registration, indexing and centralized management of all atomic units, and is equipped with atomic resource addressing, load balancing and failover mechanisms, which can realize intelligent resource allocation and status monitoring, change the traditional decentralized resource management mode and improve resource utilization.

[0021] 4. This invention establishes a system-level resource access control architecture, implementing multi-layered security verification including request anomaly pre-detection, secure message encapsulation, anti-replay and anti-spoofing verification, and trusted identity authentication. The security interception logic is deployed in the terminal operating system kernel, automatically generating alarm logs, ensuring traceability of security events, and fully meeting the high security protection requirements of police scenarios.

[0022] In summary, this invention solves the technical pain points of traditional mobile police terminals in terms of software and hardware function calls and maximizing capability release, achieving an overall improvement in terminal comprehensive performance and security capabilities, and has high practical application value. Attached Figure Description

[0023] Figure 1 This is a flowchart of the atomic resource capability encapsulation stage method in Embodiment 1 of the present invention; Figure 2 This is a flowchart of the service invocation and system resource scheduling phases in Embodiment 1 of the present invention; Figure 3 This is a flowchart of the method in Embodiment 2 of the present invention. Detailed Implementation

[0024] The present invention will be further described below with reference to the accompanying drawings. It should be noted that this embodiment is based on the present technical solution and provides detailed implementation methods and specific operation processes, but the protection scope of the present invention is not limited to this embodiment.

[0025] Example 1

[0026] This embodiment provides a method for atomication and dynamic scheduling of mobile police terminal resources, including an atomic resource capability encapsulation stage and a service invocation and system resource scheduling stage.

[0027] like Figure 1 As shown, the atomic resource capability encapsulation stage specifically includes the following steps: A1. Decoupling and Abstraction of Hardware Resources at the Bottom Layer. Through the Hardware Abstraction Layer (HAL) and a unified device model, the direct binding between the underlying hardware (including multi-core CPU, NPU, audio and video acquisition unit, positioning module, national cryptographic encryption engine, Trusted Execution Environment (TEE), etc.) in mobile police terminals and upper-layer business applications is removed. By defining a standardized hardware access interface layer, the differences in hardware interfaces, driver versions, and register operations of different models of mobile police terminals are shielded, thus constructing a unified resource abstraction model that is independent of hardware.

[0028] A2. Atomized decomposition of hardware resources.

[0029] Hardware atomic units are broken down by function: general computing and AI inference acceleration resources are encapsulated as independent computing power atomic units into computing power atomic sets; audio and video acquisition, positioning, and environmental perception peripherals are encapsulated as independent perception atomic units into perception atomic sets; national cryptographic algorithm engine, secure storage, trusted root, and TEE environment are encapsulated as independent atomic units into security atomic sets; each hardware atomic unit is independently maintained by the operating system's atomic resource scheduling module (specifically, the atomic resource scheduling modules of the system service layer and framework layer, which run with the operating system at boot as system components) to maintain resource status (such as capability on / off) and capability interfaces (such as getCert()), thus realizing the modularization and atomic decomposition of hardware resources.

[0030] A3. Encapsulate the system-level atomic capability interfaces. This includes the following steps: (31) Abstract and adapt the driver layer operations, and define a unified set of calling parameters, return formats, error codes and control instructions.

[0031] (32) Provide task scheduling and load balancing interfaces for computing power atomic units, data acquisition and parameter configuration interfaces for perception atomic units, encryption / decryption and signature verification interfaces for security atomic units, and encapsulate the hardware atomic capability interfaces provided for each hardware atomic unit into the kernel mode and system service layer to avoid direct access to the underlying hardware by user mode.

[0032] A4. Atomized disassembly of pre-installed system software.

[0033] The independently pre-installed police business applications are split into independent business service modules according to their functions; through dependency injection and interface decoupling, hard-coded dependencies and direct resource consumption are removed, as well as the coupling between business logic and underlying hardware resources, so as to achieve lightweight and stateless transformation of business services.

[0034] A5. Extract the atomic units of business functions. This includes: (51) Extract the Single Sign-On (SSO) atom from the identity authentication function service and encapsulate cross-application single sign-on and identity ticket verification capabilities; (52) Extract feature comparison atoms from data processing services and encapsulate feature extraction and comparison matching algorithms such as face / fingerprint; (53) Extract AI agent atoms from intelligent analysis services and encapsulate multimodal reasoning, rule engine and decision analysis capabilities.

[0035] Each business function atomic unit maintains only a single business function atomic service interface, with independent call entry and status management.

[0036] A6. Encapsulate system-level atomic service interfaces. System-level atomic service interfaces provide various calling methods, such as APIs and Native SDKs, for business function atomic service interfaces. They define interface permission levels, call frequency thresholds, data format specifications, and error handling mechanisms. Through service registration and discovery mechanisms, system-level atomic service interfaces enable dynamic addressing of business function atomic services. They encapsulate the underlying protocol interaction logic, providing a simplified call entry point for upper-layer business applications.

[0037] A7. Construct a normalized interface for atomic resource scheduling. The normalized interface for atomic resource scheduling adopts a unified message queue and protocol adaptation layer, which is compatible with different calling protocols of hardware atomic capability interfaces and business function atomic service interfaces. By defining standardized atomic call request and response message formats, and encapsulating protocol conversion, parameter adaptation, and format verification logic, it achieves compatibility between different types and versions of hardware atomic capability interfaces and business function atomic service interfaces.

[0038] A8. The atomic resource pool has completed unified registration. This includes: (A81) Enter metadata such as atomic ID, atomic type, capability description, resource capacity, call constraints, security level, and status information for each hardware atomic unit and business function atomic unit; (A82) Construct an atomic resource catalog service to support fast retrieval by atomic type, capability tag, and security level.

[0039] like Figure 2 As shown, the business invocation and system resource scheduling phase includes the following steps: B1. The business application initiates an atomic call request. The atomic call request message carries the business scenario identifier, target atomic unit ID, call context parameters, application identity credentials, and request priority; the business application sends the atomic call request to the atomic resource scheduling normalization interface of the atomic resource scheduling module, while also carrying session context information.

[0040] B2. The atomic resource scheduling normalization interface performs abnormal behavior pre-checks on atomic call requests initiated by business applications. Specifically, based on an exception rule base, the atomic resource scheduling normalization interface uses a rule engine to perform real-time analysis of atomic call request messages, call frequency, and application identity. The exception rule base includes rules for unauthorized calls, high-frequency malicious requests, abnormal parameters, and abnormal scenario matching. If an abnormal rule is matched, the request is directly intercepted, and a security alarm log containing the request source, exception type, and timestamp is generated, at which point the process terminates.

[0041] B3. The atomic resource scheduling normalization interface performs secure message encapsulation on atomic call requests that pass the pre-check. The atomic call request message embeds the device ID, a dynamic session token (issued by a trusted authentication center), the current timestamp, and a password-secure random number. The dynamic session token contains the application identity, permission level, and session validity period; the timestamp is accurate to the millisecond; and the random number ensures the uniqueness of each request message.

[0042] B4. The atomic resource scheduling module performs anti-replay and anti-forgery self-verification on the encapsulated security messages. This includes: (B41) Verify whether the timestamp is within the preset time window (±30 seconds) to prevent timeout replay attacks; (B42) Verify that the random number is unique in the global request cache to prevent duplicate requests; (B43) Verify message integrity through message digest verification (using the national cryptographic SM3 algorithm) to prevent message tampering; If any of the above checks fail, the request is intercepted and a security alert log is generated, and the process terminates.

[0043] B5. The atomic resource scheduling module calls the trusted verification interface of the kernel-level trusted function component to perform kernel trusted authentication and dynamic permission verification on the security messages that have passed the verification in step B4. This includes: First, the device ID and dynamic token are verified for legitimacy using a kernel-mode whitelist, confirming the issuing authority, validity period, and integrity of the token. Then, based on the business permission mapping table, the permission level of the application identity is verified to match the access control list (ACL) of the target atomic resource. If the identity is invalid or the permissions are non-compliant, the request is intercepted and a security alarm log is generated, and the process terminates. If the verification passes, the atomic resource scheduling module allocates atomic units to the business application according to the request priority and atomic resource load, realizing the scheduling management of atomic unit allocation, preemption, etc.

[0044] B6. Business applications invoke allocated atomic units to execute business tasks. Based on business scenario requirements, business applications schedule the capabilities of atomic units, such as invoking computing atoms to perform AI inference, invoking perception atoms to collect audio and video data, and invoking security atoms to encrypt data. Data interaction and task collaboration between atomic units are achieved through the inter-atomic communication bus, strictly adhering to task flows to execute data processing, feature comparison, intelligent analysis, and other business operations. Simultaneously, the monitoring module collects the real-time operating status and task progress of the atomic units.

[0045] B7. Update atomic resource status and release resources. After the business task is completed, the atomic resource scheduling module marks the atomic unit as idle, releases the occupied CPU, memory, peripherals and other system resources, and clears the task context data; writes the atomic unit's running log and task result metadata to the atomic resource pool; updates the atomic unit's status to the global atomic resource directory through the status synchronization mechanism, so that it returns to the atomic resource pool and waits for the next scheduling call; and clears the temporary tokens and cached data of this session.

[0046] In this embodiment, after the atomic resource capability encapsulation stage is completed, there is also a process of initializing the atomic resources of the mobile police terminal and pre-deploying the scheduling rules: After the mobile police terminal is powered on and completes system initialization, each hardware atomic unit and business function atomic unit is uniformly registered and filed, and inherent attribute parameters such as power consumption level, business affiliation label, scene adaptation permission, and scheduling priority are fixed for all hardware atomic units and business function atomic units. At the same time, a mapping rule library containing scene level and atomic resource adaptation whitelist is constructed.

[0047] Based on this, in step B5, the specific process by which the atomic resource scheduling module allocates atomic units to the business application according to request priority and atomic resource load is as follows: C1. Current time-series business scenario feature value collection and standardization processing. The business application triggers a call to the atomic unit (hardware atomic unit and / or business function atomic unit) at time t, collects the business scenario feature value at time t, and performs normalized feature processing.

[0048] The business scenario feature values ​​include: X1(t) is the alarm level feature (value range 1-5); X2(t) is the task type feature (value range 1-20); X3(t) is the terminal computing power load feature (value range 0%-100%); X4(t) is the network transmission quality feature (value range 1-5); X5(t) is the environmental security attribute feature (value range 1-4); and X6(t) is the resource trust status feature (value range 1-3).

[0049] The formula for normalized feature processing is as follows: ; In the formula, x i ( t ) represents the normalized feature value corresponding to the i-th dimension of the business scenario feature; X i,min , X i,max They are respectively X i ( t The preset maximum and minimum values ​​of ) are the endpoint values ​​of the preset value range.

[0050] For example, the business scenario feature vector at time t. X The collected values ​​(t) = [4.5, 18, 82, 4.6, 3.7, 2.8] are all within the compliant range. After normalization, the standardized feature vector is obtained. x ( t = [0.88, 0.89, 0.82, 0.90, 0.90, 0.90].

[0051] C2. Multi-dimensional feature weighted fusion, calculate the instantaneous scene comprehensive score according to the following formula. S ( t ): ; w i The weights are the corresponding to the i-th dimension of the business scenario features.

[0052] For example, the standardized feature vectors obtained above x ( t The formula is: ) = [0.88, 0.89, 0.82, 0.90, 0.90, 0.90], combined with preset fixed weights. w =[0.35,0.20,0.15,0.15,0.10,0.05]; the instantaneous comprehensive score of the scene is calculated. S ( t =0.879.

[0053] C3. Exponential smoothing anti-jitter filtering generates a steady-state scene score. Specifically, a first-order exponential smoothing filter algorithm is used to suppress transient disturbances and avoid system architecture misreconstruction caused by frequent scene jumps. In this embodiment, a fixed smoothing coefficient λ=0.4 is set to balance scene response sensitivity and system operation stability. The steady-state scene score calculation formula is as follows: ; Where S*(t-1) is the steady-state scene score of the previous moment; the operating system initializes the first frame without historical data, so the steady-state scene score of the first frame is equal to the instantaneous comprehensive score by default.

[0054] C4. Dual-threshold quantization judgment, outputting a three-level police scenario rating. Based on steady-state scenario scoring. S* ( t According to the preset threshold T 1 and T 2. Obtain scene level results L ( t ): ; C5. Based on the scenario level results obtained in step C4, allocate atomic unit resources to the current business application using the corresponding scheduling mechanism.

[0055] If the calculation in step C4 yields L ( t )=1, corresponding to the atomic unit scheduling request in a normal duty scenario, according to priority P j (t) allocates the atomic unit resources explicitly required for the current call request, without actively releasing other allocated low-priority scheduling resources. When atomic resources are insufficient to complete the allocation, unnecessary background processes or idle atomic units are manually released until the minimum resources required for the current business call are met.

[0056] If the calculation in step C4 yields L ( t =2, corresponding to atomic unit scheduling requests in general alarm scenarios, only retains atomic resources required by the current business call and necessary background services, and allocates non-essential background redundant processes and idle atomic units according to priority P. j (t) From low to high, resources are automatically released according to the resource occupancy rate to ensure the allocation of computing power and storage for the current business, while reserving the operating resources for the basic daily duties of the mobile police terminal.

[0057] If the calculation in step C4 yields L ( t When )=3, corresponding to atomic unit scheduling requests in critical emergency scenarios, a kernel-level resource preemption and isolation mechanism is initiated; the current list of all atomic unit calling processes is traversed, and all low-priority processes (P) are prioritized. j (t)<Pth The scheduling process and background redundant resources are forcibly released using the `free` method. j This service call exclusively utilizes the current atomic unit resources, increasing the terminal NPU computing power utilization rate to 95%. The latency of video transmission and situation reporting is effectively guaranteed, and the entire service process is free from lag and terminal risks caused by competition for computing power and CPU resources.

[0058] P j (t) represents the priority of the j-th scheduling process at time t, where j is the scheduling process number used to distinguish different scheduling processes; t is the current time point; P th It is the priority threshold.

[0059] In this embodiment, L ( t In the scenario where )=3, the system iterates through the priorities of existing scheduling processes, and when there is a scheduling process P... j (t) is lower than the set threshold P th In this case, the scheduling process will be classified as a low-priority process, and the atomic unit resources it occupies will be taken care of. L ( t The currently urgently needed business with a value of 3 will be forcibly released to ensure [the following]. L ( t Resource requirements for high-priority services with a priority of 3.

[0060] P th It is a priority value that the operating system periodically evaluates all current process calls to determine (simply put, it's like queuing up a process, taking a boundary from within that queue, and randomly releasing resources below P when resources are insufficient). th The scheduling process performs a free operation to release memory and CPU.

[0061] For example, in this embodiment, S*(t) is calculated to be 0.4·0.879+(1-0.4)·0.8=0.8316, and is set as follows: T 1 = 0.35 T If 1 = 0.70, then the scene level result can be obtained: L ( t )=3 This corresponds to atomic unit scheduling requests in critical emergency scenarios, thus triggering a kernel-level resource preemption and isolation mechanism.

[0062] For those skilled in the art, various corresponding changes and modifications can be made based on the above technical solutions and concepts, and all such changes and modifications should be included within the protection scope of the claims of this invention.

Claims

1. A method for atomizing and dynamically scheduling resources in a mobile police terminal, characterized in that, This includes the atomic resource capability encapsulation phase, as well as the business invocation and system resource scheduling phases; The atomic resource capability encapsulation stage specifically includes the following steps: A1. Hardware Resource Decoupling and Abstraction: Through a hardware abstraction layer and a unified device model, the direct binding between the underlying hardware and upper-layer business applications in the mobile police terminal is removed; by defining a standardized hardware access interface layer, the differences in hardware interfaces, driver versions and register operations of different models of mobile police terminals are shielded, and a unified resource abstraction model independent of hardware is constructed. A2. Atomized decomposition of hardware resources: Hardware atomic units are broken down by function, and each hardware atomic unit has its resource status and capability interface maintained independently by the atomic resource scheduling module of the operating system. A3. Encapsulating system-level atomic capability interfaces: This includes the following steps: (31) Abstract and adapt the driver layer operations, and define a unified set of calling parameters, return formats, error codes and control instructions; (32) Provide hardware atomic capability interfaces for each hardware atomic unit, and encapsulate the hardware atomic capability interfaces provided for each hardware atomic unit into the kernel mode and system service layer to avoid direct access to the underlying hardware by the user mode; A4. Atomized Disassembly of Pre-installed System Software: The independently pre-installed police business applications are split into independent business service modules according to their functions; through dependency injection and interface decoupling, hard-coded dependencies and direct resource consumption are separated, as well as the coupling between business logic and underlying hardware resources are separated. A5. Extract the atomic units of business functions; including: (51) Extract the single sign-on atom from the identity authentication function service and encapsulate cross-application single sign-on and identity ticket verification capabilities; (52) Extract feature comparison atoms from data processing services and encapsulate feature extraction and comparison matching algorithms; (53) Extract AI agent atoms from intelligent analysis services and encapsulate multimodal reasoning, rule engine and decision analysis capabilities; Each business function atomic unit maintains only a single business function atomic service interface, and has an independent call entry point and status management; A6. Encapsulate system-level atomic service interfaces; system-level atomic service interfaces provide multiple calling methods for business function atomic service interfaces, and define interface permission levels, call frequency thresholds, data format specifications, and error handling mechanisms; system-level atomic service interfaces realize dynamic addressing of business function atomic services through service registration and discovery mechanisms; system-level atomic service interfaces encapsulate underlying protocol interaction logic; A7. Construct a normalized interface for atomic resource scheduling; the normalized interface for atomic resource scheduling adopts a unified message queue and protocol adaptation layer, which is compatible with different calling protocols of hardware atomic capability interfaces and business function atomic service interfaces. By defining standardized atomic call request and response message formats, and encapsulating protocol conversion, parameter adaptation and format verification logic, it achieves compatibility of different types and versions of hardware atomic capability interfaces and business function atomic service interfaces. A8. The atomic resource pool has completed unified registration, including: (A81) Enter metadata for each hardware atomic unit and business function atomic unit, including atomic ID, atomic type, capability description, resource capacity, call constraints, security level and status information; (A82) Construct an atomic resource catalog service to support fast retrieval by atomic type, capability tag, and security level; The business invocation and system resource scheduling phase includes the following steps: B1. The business application initiates an atomic call request; the atomic call request message carries the business scenario identifier, target atomic unit ID, call context parameters, application identity credentials and request priority; the business application sends the atomic call request to the atomic resource scheduling normalization interface of the atomic resource scheduling module, while also carrying session context information; B2. The atomic resource scheduling normalization interface performs abnormal behavior pre-checks on atomic call requests; B3. The atomic resource scheduling normalization interface implements secure message encapsulation for atomic call requests that pass the pre-check: embedding the device ID, dynamic session token, current timestamp, and password-secure random number into the atomic call request message; wherein the dynamic session token contains the application identity, permission level, and session validity period; B4. The atomic resource scheduling module performs anti-replay and anti-forgery self-verification on the encapsulated security messages; B5. The atomic resource scheduling module calls the trusted verification interface of the kernel layer trusted function component to perform kernel trusted authentication and dynamic permission verification on the security message that has passed the verification in step B4; after the verification is passed, the atomic resource scheduling module allocates atomic units to the business application according to the request priority and atomic resource load. B6. Business applications call the allocated atomic units to execute business tasks, and at the same time, the monitoring module collects the running status and task progress of the atomic units in real time. B7. Update the atomic resource status and release the resources.

2. The method according to claim 1, characterized in that, In step A2, general computing and AI inference acceleration resources are encapsulated as independent computing power atomic units into a computing power atomic set; audio and video acquisition, positioning and environmental perception peripherals are encapsulated as independent perception atomic units into a perception atomic set; and the national cryptographic algorithm engine, secure storage, trusted root and TEE environment are encapsulated as independent security atomic units into a security atomic set.

3. The method according to claim 1, characterized in that, In step B2, the atomic resource scheduling normalization interface uses an exception rule base to perform real-time analysis of atomic call request messages, call frequency, and application identity through a rule engine. If an exception rule is matched, the request is directly intercepted, and a security alarm log containing the request source, exception type, and timestamp is generated, at which point the process terminates.

4. The method according to claim 1, characterized in that, The specific process of step B4 is as follows: (B41) Verify whether the timestamp is within the preset time window to prevent timeout replay attacks; (B42) Verify that the random number is unique in the global request cache to prevent duplicate requests; (B43) Verify message integrity through message digest verification to prevent message tampering; If any of the above checks fail, the request is intercepted and a security alert log is generated, and the process terminates.

5. The method according to claim 1, characterized in that, In step B5, the specific verification process is as follows: First, the device ID and dynamic token are verified using a kernel-mode whitelist to confirm their legitimacy, including the issuing authority, validity period, and integrity of the token. Then, based on the business permission mapping table, the permission level of the application identity is checked to see if it matches the access control list of the target atomic resource. If the identity is invalid or the permissions are non-compliant, the request is intercepted and a security alarm log is generated, and the process terminates.

6. The method according to claim 1, characterized in that, The specific process of step B7 is as follows: After the business task is completed, the atomic unit is marked as idle, the occupied system resources are released, and the task context data is cleared; the running log and task result metadata of the atomic unit are written to the atomic resource pool; the state of the atomic unit is updated to the global resource directory through the state synchronization mechanism, so that it returns to the atomic resource pool and waits for the next scheduling call; the temporary token and cached data of this session are cleared.

7. The method according to claim 1, characterized in that, After the atomic resource capability encapsulation stage is completed, there is also a process of initializing and pre-deploying atomic resources and scheduling rules for mobile police terminals: After the mobile police terminal is powered on and completes system initialization, each hardware atomic unit and business function atomic unit is uniformly registered and filed, and inherent attribute parameters such as power consumption level, business affiliation label, scene adaptation permission and scheduling priority are fixed for all hardware atomic units and business function atomic units. At the same time, a mapping rule library containing scene level and atomic resource adaptation whitelist is constructed.

8. The method according to claim 7, characterized in that, In step B5, the specific process by which the atomic resource scheduling module allocates atomic units to business applications based on request priority and atomic resource load is as follows: C1. Current time-series business scenario feature value collection and standardization normalization processing: The business application triggers the call to the atomic unit at time t, collects the business scenario feature value at time t, and performs normalization feature processing; The business scenario feature values ​​include: X1(t) is the alarm level feature; X2(t) is the task type feature; X3(t) is the terminal computing power load feature; X4(t) is the network transmission quality feature; X5(t) is the environmental security attribute feature; X6(t) is the resource trust status feature; The formula for normalized feature processing is as follows: ； In the formula, x i ( t ) represents the normalized feature value corresponding to the i-th dimension of the business scenario feature; X i,min , X i,max They are respectively X i ( t The preset maximum and preset minimum values; C2. Multi-dimensional feature weighted fusion, calculate the instantaneous scene comprehensive score according to the following formula. S ( t ): ； w i The weights corresponding to the i-th dimension of the business scenario features; C3. Exponential smoothing and de-jitter filtering to generate a steady-state scene score S*(t): ； Where S*(t-1) is the steady-state scene score of the previous moment; the operating system initializes the first frame without historical data, so the steady-state scene score of the first frame is equal to the instantaneous comprehensive score by default; C4. Dual threshold quantization judgment, outputting a three-level police scenario rating; based on steady-state scenario scoring. S* ( t According to the preset threshold T 1 and T 2. Obtain scene level results L ( t ): ； C5. Based on the scenario level results obtained in step C4, allocate atomic unit resources to the current business application using the corresponding scheduling mechanism.

9. The method according to claim 8, characterized in that, The specific process of step C5 is as follows: If the calculation in step C4 yields L ( t )=1, corresponding to the atomic unit scheduling request in a normal duty scenario, according to priority P j (t) Allocates the atomic unit resources explicitly required for the current call request, without actively releasing other allocated low-priority scheduling resources. When atomic resources are insufficient to complete the allocation, unnecessary background processes or idle atomic units are manually released until the minimum resources required for the current business call are met; If the calculation in step C4 yields L ( t The atomic unit scheduling request corresponding to a general alarm scenario is 2. Only atomic resources required for the current business call and necessary background services are retained. Unnecessary background redundant processes and idle atomic units are scheduled according to priority P. j (t) From low to high, resources are automatically released according to the resource utilization rate to ensure the allocation of computing power and storage for the current business, while reserving the operating resources for the basic daily duties of the mobile police terminal. If the calculation in step C4 yields L ( t When )=3, corresponding to atomic unit scheduling requests in critical emergency scenarios, a kernel-level resource preemption and isolation mechanism is initiated; the current atomic unit calling process list is traversed, and all low-priority (P) processes are prioritized. j (t)<P th The scheduling process and background redundant resources are forcibly released using the `free` function. j This business call exclusively occupies the current atomic unit resource; P j (t) represents the priority of the j-th scheduling process at time t, where j is the process number used to distinguish different scheduling processes; t is the current time point; P th It is the priority threshold.

Images