Method, device and storage medium for controlling public safety screen based on ai

Abstract

This application discloses an AI-based control method, device, and storage medium for public safety screens, relating to the field of Internet of Things (IoT) technology. The method includes: responding to an account login operation, determining screen control information within the scope of the account's control permissions; responding to a screen control request based on the screen control information, generating a screen control policy by combining the priority of the screen control request; mapping control instructions to the target screen according to the screen control policy and its corresponding target screen's status information; and issuing control instructions according to the timing of the control instructions to control the target screen. This application solves the problem of low efficiency in screen operation and maintenance management by determining corresponding screen control information by matching the control permission scope after account login, generating control policies according to the priority of control requests, adapting and generating control instructions, and issuing control instructions according to the timing. This improves control accuracy, compliance, and emergency response efficiency.

Description

Technical Field

[0001] This application relates to the field of Internet of Things (IoT) technology, and in particular to a control method, device, and storage medium for an AI-based public safety screen. Background Technology

[0002] In public environment screen operation and maintenance scenarios, the degree of centralization of terminal management and the speed of scheduling response directly affect the stability of scenario operation and the efficiency of equipment management and maintenance.

[0003] In the process of unified management and control of public screens across regions, the relevant technologies typically employ a manual on-site operation mode. This approach relies on manual management and on-site handling of each screen locally, resulting in significant delays in cross-regional scheduling and consequently, low efficiency in screen operation and maintenance management.

[0004] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0005] The main purpose of this application is to provide an AI-based control method, device, and storage medium for public safety screens, aiming to solve the technical problem of low efficiency in screen operation and maintenance management.

[0006] To achieve the above objectives, this application proposes an AI-based control method for public safety screens, the method comprising:

[0007] In response to an account login operation, screen control information within the scope of the account's control permissions is determined. In response to the screen control request in the screen control information, a screen control policy is generated based on the priority of the screen control request; Based on the screen control strategy and the status information of the corresponding target screen, the control instructions for the target screen are mapped to obtain the control instructions for the target screen. The control commands are sent according to the specified timing to control the target screen.

[0008] In one embodiment, after completing the account login operation and generating the identity credential corresponding to the account, the corresponding hierarchical control permissions and geographical jurisdiction boundaries are matched in the permission management database based on the identity credential. Based on the hierarchical control permissions and the geographical jurisdiction boundaries, and combined with environmental weighting calculations, the scope of control permissions for the account is determined. Based on the scope of the account's management permissions, screen management information within the scope of the management permissions is filtered out from the full screen information and displayed.

[0009] In one embodiment, a login location weight is generated based on the login location of the account and the factors influencing the login location, according to a weighting rule. Based on the environmental impact factors of the scene where each screen to be managed is located, the weights of the impact factors are generated according to the environmental impact additional rules. The environmental weight is calculated by combining the landing site weight with the impact factor weight and a preset weight ratio. The hierarchical control permissions and the geographical control boundaries are respectively weighted by the environmental weights to obtain the weighted hierarchical permissions and the weighted geographical boundaries. According to the permission scope determination rules, the conflict between the weighted hierarchical permissions and the weighted geographical boundary permission scope is adjusted to obtain the management permission scope of the account.

[0010] In one embodiment, in response to the screen control request, the priority of the screen control request is calculated by weighting according to the control type of the screen control request, the corresponding screen state and the security level of the scene in which the screen is located, according to the priority weighting rules. Based on the priority of the screen control request, compare it with the priority of conflicting screen control requests to obtain the priority comparison result; After adjusting the screen control request based on the priority comparison result, the screen control strategy is generated according to the adjusted screen control request and its corresponding execution sequence.

[0011] In one embodiment, the screen control strategy is parsed, and control parameters are obtained by combining the operating parameters of the target screen; Based on the status information of the target screen corresponding to the screen control strategy, the power type and control link attributes of the target screen are determined; Based on the power type of the target screen and the attributes of the control link, the adaptability of the control parameters is verified, and the adaptability parameters are adjusted to obtain the appropriate parameters. The adaptation parameters are mapped into control commands that conform to the target screen terminal communication according to the execution encoding mapping rules.

[0012] In one embodiment, the sending sequence of the control command corresponding to the screen control request is determined based on the execution sequence of the screen control request and the corresponding link delay; Based on the transmission timing, the control commands are sent sequentially to the corresponding target screens via IoT communication services. The system receives terminal receipt information and instruction execution status transmitted from the target screen to control the target screen to complete the content of the control instruction.

[0013] In one embodiment, based on the screen control information within the scope of the control authority, the devices are hierarchically classified according to the administrative tree structure to obtain list-style screen device information and real-time online and offline status data; The list-style screen device information and the real-time online and offline status data are linked together with the status list according to multi-dimensional statistical rules to quantify and generate screen health data. Based on the screen health data, the device communication and working status of the screen are detected, and a graded alarm is triggered and historical alarm records are archived when an abnormality occurs.

[0014] In one embodiment, the operating power parameters of the target screen are collected via an IoT control box; The power type of the target screen is determined based on the operating power parameters and power parameter thresholds. Match the corresponding management link according to the power type, and configure the exclusive adaptation configuration of the management link according to the link configuration parameter library; Based on the scenario requirements and communication deployment strategy of the target screen, deploy a hierarchical communication scheme for the target screen; Based on the adapted control link and the hierarchical communication deployment scheme, a two-way data communication channel is constructed between the public screen management platform and the IoT control box, providing transmission support for the issuance of control commands and the feedback of terminal status.

[0015] Furthermore, to achieve the above objectives, this application also proposes an AI-based control device for a public safety screen, the AI-based control device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the AI-based control method for the public safety screen as described above.

[0016] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the AI-based public safety screen control method described above.

[0017] This application provides an AI-based method for controlling public safety screens. The method includes determining screen control information within the scope of account control permissions based on the account's login operation; generating a matching screen control policy in response to a screen control request initiated based on the aforementioned screen control information and the priority of the request; obtaining a dedicated control command adapted to the target screen based on the generated screen control policy and the real-time status information of the target screen; and finally, issuing the control command according to a preset sending sequence to achieve precise remote control of the target screen. This method solves the problems commonly found in existing public safety screen control fields, such as insufficient granularity of hierarchical permission control, ambiguous boundaries of cross-level and cross-regional control permissions, and multiple sources of control information. The system addresses technical issues such as the lack of priority scheduling for control requests leading to control conflicts, poor compatibility between control commands and target screen device attributes and operating status, low control efficiency due to the lack of a closed-loop control process, insufficient security and controllability, and weak emergency response capabilities. It improves the accuracy and compliance of hierarchical access control for public safety screens, enables the orderly scheduling of multi-source control requests and the early resolution of control conflicts, ensures accurate adaptation of control commands to target screen device attributes and real-time operating status, and constructs a closed-loop remote hierarchical control system. This significantly enhances the real-time performance, reliability, security protection level, and emergency response efficiency of centralized control of public safety screens, while also achieving standardized, refined, and intelligent full lifecycle control of public safety screens.

[0018] In summary, this application solves the problem of low efficiency in screen operation and maintenance management by determining the corresponding screen control information by matching the scope of control permissions after account login, generating control policies according to the priority of control requests, adapting and generating control instructions and issuing control in sequence, thereby improving the accuracy, compliance and emergency response efficiency of control. Attached Figure Description

[0019] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

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

[0021] Figure 1 This is a flowchart illustrating the first embodiment of the AI-based public safety screen control method of this application; Figure 2 This is a system framework diagram for this application; Figure 3 This is a hierarchical geographic control map for this application; Figure 4 This is a list of screen devices for this application; Figure 5 This is a schematic diagram of the control device for the AI-based public safety screen of this application.

[0022] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0023] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0024] In the process of unified management and control of public screens across regions, the relevant technologies typically employ a manual on-site operation mode. This approach relies on manual management and on-site handling of each screen locally, resulting in significant delays in cross-regional scheduling and consequently, low efficiency in screen operation and maintenance management.

[0025] This application provides a solution: First, in response to an account login operation, screen control information within the scope of the account's control permissions is determined. Then, in response to a screen control request in response to the screen control information, a screen control policy is generated based on the priority of the screen control request. Next, control instructions for the target screen are mapped according to the screen control policy and the status information of the corresponding target screen. Finally, the control instructions are sent according to the sending sequence of the control instructions to control the target screen.

[0026] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device capable of performing the above functions, such as an AI-based public safety screen control device. The following description uses an AI-based public safety screen control device as an example to illustrate this embodiment and the subsequent embodiments.

[0027] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0028] This application provides an AI-based control method for public safety screens, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the AI-based public safety screen control method of this application.

[0029] In this embodiment, the AI-based public safety screen control method includes steps S10~S40: Step S10: In response to the account login operation, determine the screen control information within the scope of the control permissions based on the account's control permissions.

[0030] In this embodiment, account login refers to the process of submitting identity verification information, completing system legitimacy verification, and obtaining system access privileges. Control permission scope refers to the control permissions set based on the account's corresponding identity credentials, which include the executable control operations and the jurisdiction of the screens that can be controlled. Screen control information refers to basic information related to the screen device attributes, operating status, and geographical distribution that supports screen control operations.

[0031] Optionally, in response to an account login operation, the agent determines the account corresponding to the login operation and, based on the account's control authority scope, determines the screen control information within that scope. The agent is pre-trained and can automatically execute the relevant processes of the AI-based public safety screen control method.

[0032] As an optional implementation, after completing the account login operation and performing a full verification of the submitted identity information, a unique identity credential is generated for that account. Based on the generated identity credential, a matching process is performed in a pre-defined permission management database to retrieve the hierarchical control permissions and geographical jurisdiction boundaries corresponding to the account. After retrieval, a weighted calculation is performed using pre-defined environmental weighting rules to adapt and adjust the coverage dimensions of the hierarchical control permissions and the coverage scope of the geographical jurisdiction boundaries. After completing permission conflict verification, the scope of control permissions for the account is determined. Based on the determined scope of control permissions, targeted filtering is performed on all screen information stored in the system to extract the corresponding screen control information within the scope of control permissions and present it visually.

[0033] As an alternative implementation, upon completing the account login operation, a dynamic identity credential bound to the current login session is generated. Based on the generated identity credential, real-time synchronization and matching are performed in the permission management database. The basic hierarchical control permissions and initial geographic jurisdiction boundaries corresponding to the account are retrieved, and real-time environmental impact parameters corresponding to this login are collected synchronously. Combined with preset weight calculation rules, real-time weighted calculations are performed to dynamically adjust the hierarchical control permission level and the coverage of the geographic jurisdiction boundary. After completing multi-dimensional permission conflict verification, the real-time control permission range corresponding to this login session of the account is determined. Based on the determined control permission range, real-time filtering and dynamic updates are performed in the full screen information database to extract and continuously synchronize and display the corresponding screen control information within the control permission range.

[0034] Step S20: In response to the screen control request of the screen control information, generate a screen control policy based on the priority of the screen control request.

[0035] In this embodiment, a screen control request refers to a compliance application initiated based on screen control information already determined within the account's permissions, to perform specified control operations on a target screen. The priority of a screen control request refers to a hierarchical identifier used to distinguish the order of execution of control requests, system resource allocation weight, and execution permission level. A screen control strategy refers to a control execution plan that adapts to the core requirements of the control request, matches priority rules, and possesses complete executability.

[0036] As an optional implementation, in response to a received screen control request initiated based on screen control information, the control type, target screen status information, and security level of the target screen's scene corresponding to the screen control request are extracted. A weighted calculation is performed based on priority weight rules to obtain the priority of the screen control request. The priority of this screen control request is then compared item by item with the priorities of currently pending screen control requests that conflict with execution, yielding a priority comparison result. Based on the priority comparison result, the execution sequence and scope of this screen control request are adapted and adjusted. After eliminating control execution conflicts, a standardized screen control strategy is generated according to the adjusted screen control request and its corresponding execution sequence.

[0037] As an alternative implementation, in response to a received screen control request based on screen control information, the system simultaneously extracts the control type corresponding to the request, the target screen's status information, the security level of the screen's environment, and the real-time control permission level of the requesting account. A multi-dimensional real-time weighted calculation is performed based on priority weight rules to obtain the real-time priority of the screen control request. This dynamic real-time priority is then compared and conflict-checked with all screen control requests in the entire system that are in a pending or scheduled state, resulting in a priority comparison result and a control conflict list. Based on the comparison result and conflict list, the execution sequence, execution scope, and execution path of this screen control request are adapted and adjusted. After resolving control conflicts, an adaptive screen control strategy is generated according to the adjusted screen control request and its corresponding optimized execution sequence.

[0038] Step S30: Based on the screen management strategy and the status information of the corresponding target screen, the control command of the target screen is mapped to obtain the control command of the target screen.

[0039] In this embodiment, the target screen's status information refers to real-time operating parameters, power attributes, control link status, and other real-time data related to the device's operating condition. Control commands are execution messages that can be recognized by the target screen's corresponding terminal device and directly triggered to perform corresponding control actions, enabling changes to the target screen device's operating status according to the content of the control commands.

[0040] As an optional implementation method, the explicit control execution targets and rules in the screen control strategy are extracted, and parameter conversion is performed by combining the target screen's operating parameters to generate initial control parameters. Based on the state information of the target screen corresponding to the screen control strategy, the power type and control link attributes of the target screen are extracted to complete the attribute determination of the control execution object. Based on the determined power type and control link attributes of the target screen, the initial control parameters are subjected to adaptability verification to obtain the verification result. The control parameters are adapted and adjusted according to the verification result to generate adapted parameters that match the target screen attributes. The adapted parameters are then format-converted and content-mapped according to the execution encoding mapping rules to generate control instructions that conform to the target screen terminal communication specifications.

[0041] As an alternative implementation, the control execution target, execution rules, and security constraints in the screen control strategy are extracted. These are then combined with the target screen's operating parameters and permission constraints to perform parameter transformation, generating initial control parameters with security verification identifiers. Based on the real-time status information of the target screen corresponding to the screen control strategy, a multi-dimensional determination of the target screen's power type, control link attributes, terminal communication specifications, and real-time operating conditions is performed, yielding multi-dimensional determination results. Based on these multi-dimensional determination results, the initial control parameters undergo adaptability and execution conflict verification, generating verification results. The control parameters are then dynamically adapted and adjusted according to these results, generating adapted parameters that match the target screen's real-time status. Finally, the adapted parameters are dynamically encoded, mapped, and securely encrypted according to the target screen terminal's real-time synchronized communication specifications and execution rules, generating control instructions that meet the target screen terminal's real-time communication requirements and have secure interlocking logic.

[0042] Step S40: Send the control command according to the sending sequence of the control command to control the target screen.

[0043] In this embodiment, target screen control refers to triggering the corresponding control terminal of the target screen to perform a specified control action by issuing control commands.

[0044] As an optional implementation, the transmission sequence of the control commands corresponding to the screen control request is determined based on the execution sequence of the screen control request and the fixed delay parameters of the corresponding communication link. Based on the determined transmission sequence, the control commands are transmitted to the corresponding target screen via a preset IoT communication service in chronological order, and the terminal receipt information and command execution status transmitted back from the target screen are received. Based on the receipt information and execution status, compliance verification of the command execution results is completed, and the target screen completes all control content corresponding to the control commands.

[0045] As an alternative implementation, the execution timing requirements of the screen control request are obtained, and real-time transmission delay, link connectivity status, and communication quality parameters of the corresponding communication link are collected. After multi-dimensional weighted calculations, the optimal sending timing of the control command corresponding to the screen control request is dynamically adjusted to determine. Based on the determined sending timing, the control command is synchronously sent to the corresponding target screen control through the IoT communication service with primary and backup redundancy deployment in the optimized order. The terminal receipt information, command execution status, and link status feedback data transmitted back from the target screen control are received. Based on the feedback data, compliance verification and dynamic scheduling optimization of the entire command execution process are completed, and the target screen control accurately completes all control content corresponding to the control command.

[0046] For example, refer to Figure 2 , Figure 2This is a system framework diagram for this application. In a scenario of centralized management of public security screens within a public security bureau's jurisdiction, the account login operation is first completed through the public screen management system (software platform) deployed in the upper presentation layer. The operator submits identity verification information using the district branch administrator's account. After the system completes full verification of the account's legality, it generates an identity credential uniquely bound to that account, which is then transmitted via Hypertext Transfer Protocol (HTTPS). Secure authentication completes the encrypted transmission of identity data. Based on the WebSocket Protocol (WebSocket), real-time data synchronization between the front-end page and back-end service is achieved. The system matches the corresponding hierarchical control permissions and geographical jurisdiction boundaries in the application service layer database based on the account's identity credentials. After weighted calculation combining the environmental weight of the account's login location, the system determines that the account's control permissions cover 86 public safety screens across three streets under the jurisdiction of the branch. Subsequently, the application service layer's data collection service collects real-time data on the operating status and online / offline status of all public screens. Geographic services are used to match and structure the geographical distribution data of the screens. Data services clean and filter the data, selecting screen control information within the control permission range from the total screen information and visually displaying it through the upper presentation layer. When operators initiate emergency public service announcements and broadcasts based on the presented screen control information, they can then use this information to target 24 screens along the main roads of the jurisdiction. When a screen control request is received from the source control system, the system responds to the request. Based on the control type (emergency control), the target screen's real-time status (online operation), and the screen's location being a densely populated area on a main road with a security level of Level 1, the system calculates the priority of the screen control request according to a preset priority weighting rule, assigning it the highest priority (Level 1). This priority is then compared with the three pending regular content update control requests within the system. After obtaining the priority comparison result, the execution sequence of the control request is adjusted, pausing the execution of low-priority regular requests. A corresponding screen control strategy is generated based on the adjusted screen control request and its execution sequence. The system then parses this screen control strategy, combines it with the target screen's real-time operating parameters to obtain initial control parameters, and, based on the real-time status information of the target screen corresponding to the screen control strategy, determines that the power type of 18 normal power screens is regular power supply control, and the control link attribute is Modbus-TCP (Modbus TCP). The communication method involves Transmission Control Protocol (TCP). The power type of the six ultra-high-power screens is signal source control, and the control link attribute is Message Queuing Telemetry Transport (MQTT). The compatibility of the initial control parameters is verified based on the power type and control link attribute of the target screen, and then adjusted to obtain the appropriate parameters.The adaptation parameters are mapped into control commands conforming to the target screen terminal communication specifications according to the execution encoding mapping rules. Based on the execution sequence of the screen control request and the real-time latency parameters of the corresponding communication link, the system determines the transmission sequence of each control command. Then, through IoT communication services, based on 4G / 5G signals, the control commands are sent to the controller of the corresponding target screen in the IoT control layer according to the determined transmission sequence. After receiving the control commands, the controller executes the corresponding control actions and simultaneously transmits the terminal feedback information and command execution status back to the system through the IoT communication service. After receiving the feedback information and execution status, the system completes the compliance verification of the command execution results. The target screen in the lower presentation layer completes all control content corresponding to the control commands, and the entire process control data is synchronously stored in the database of the application service layer.

[0047] By matching the scope of control permissions after account login to determine the corresponding screen control information, generating control policies according to the priority of control requests, adapting and generating control instructions and issuing control in sequence, the problem of low efficiency in screen operation and maintenance management is solved, and the control accuracy, compliance and emergency response efficiency are improved.

[0048] Based on any of the above embodiments, in Embodiment 2 of this application, step S10 includes steps A11 to A13: Step A11: After completing the account login operation and generating the identity credential corresponding to the account, match the corresponding hierarchical control permissions and geographical jurisdiction boundaries in the permission management database based on the identity credential.

[0049] In this embodiment, the identity credential refers to a standardized identity authentication carrier generated by the system after the account completes login verification. It is uniquely bound to the account holder's identity, carries the account identity identifier and permission verification information, and possesses anti-tampering and anti-counterfeiting capabilities. The permission management library refers to a standardized data storage and management unit pre-set by the system that centrally stores all account identity information, permission configuration rules, jurisdiction boundary parameters, and permission verification logic. Hierarchical control permissions refer to tiered permission configuration rules pre-set based on the account holder's responsibilities and control levels, used to distinguish the types, scope, and depth of screen control operations that the account can perform. Geographic jurisdiction boundary refers to spatial boundary rules pre-set based on the account holder's jurisdictional scope, used to limit the geographical coverage of screen devices from which the account can perform control operations.

[0050] As an optional implementation, upon completing the account login process, the submitted identity verification information undergoes multi-factor cross-validation. Upon successful validation, an identity credential uniquely bound to the account, containing embedded fixed permission verification fields and an encrypted timestamp, is generated. This generated identity credential is synchronously stored in a dedicated identity verification partition of the permission management database. Based on the generated static identity credential, a permission matching request is initiated to the permission management database. After performing decryption, anti-counterfeiting, and identity consistency verification on the static identity credential, the permission management database retrieves the configuration parameters of the hierarchical control permissions uniquely bound to the account, and also retrieves the spatial parameters of the geographical jurisdiction boundary bound to the account. After completing the compliance verification of the association between the hierarchical control permissions and the geographical jurisdiction boundary, the hierarchical control permissions and geographical jurisdiction boundary corresponding to the account's identity credential are output.

[0051] Step A12: Based on the hierarchical control permissions and the geographical jurisdiction boundaries, and combined with environmental weighting calculations, determine the scope of control permissions for the account.

[0052] In this embodiment, environmental weight refers to a weighted calculation parameter generated based on the influence factors of the account login location and the environmental influence factors of the scene where the screen to be managed is located, used to adapt and adjust the coverage and level of account management permissions. Weighted calculation refers to the permission adaptation and adjustment process that integrates the account's basic hierarchical management permissions, geographical jurisdiction boundaries, and corresponding environmental weights according to preset rules.

[0053] As an optional implementation, based on the account's login location, environmental influencing factors corresponding to the login location are extracted. Each factor is then adapted and calculated according to weighting rules to generate a unique login location weight. Environmental influencing factors corresponding to the scene of the screen to be managed are also extracted. Each screen is then independently adapted and calculated according to preset environmental influence rules to generate independent influence factor weights for each screen to be managed. The generated login location weights and the influence factor weights for each screen are then fused together using preset weight ratios to generate the independent environmental weight for each screen. The account's hierarchical management permissions and geographical jurisdiction boundaries are then weighted and calculated with the independent environmental weights for each screen to generate the weighted hierarchical permissions and weighted geographical boundaries for each screen. Based on preset permission scope judgment rules, a pre-verification of permission scope conflicts is performed on the weighted hierarchical permissions and weighted geographical boundaries for all screens. For conflicting items with overlapping permissions or boundaries, compliance adjustments are made item by item. After eliminating permission conflicts, all compliant permission and boundary data are integrated to generate the full management permission scope for the account.

[0054] Step A13: Based on the scope of the account's control permissions, filter out and display the screen control information within the scope of the control permissions from the full screen information.

[0055] In this embodiment, the full screen information refers to the complete data source set that is centrally stored and managed by the system, covering all screen devices connected to the control system, including their basic attributes, real-time operating status, geographical distribution information, control link attributes, and historical control records.

[0056] As an optional implementation, the scope of control permissions is analyzed to determine the corresponding permission level thresholds, geographical coverage boundary parameters, operable device type rules, and executable operation type constraints, forming a complete set of compliance verification rules. The full screen information stored in the database is retrieved, and the information is broken down and structured at the individual device level. For each device, its full information is matched against the compliance verification rule set in all dimensions. The system sequentially verifies whether the device's geographical distribution falls within the geographical coverage boundary, whether the device control level matches the account permission level threshold, whether the device type conforms to the operable device type rules, and whether the device's executable operations meet the account operation type constraints. The full information of devices that pass all verifications is included in the screen control information within the scope of control permissions. All device information that fails verification is filtered and intercepted. After full device verification and filtering, the screen control information within the scope of control permissions is categorized and organized according to preset structured rules, and then visualized through a front-end interactive interface.

[0057] As an alternative implementation, the system pre-analyzes all screen information stored within it, using each device as the smallest unit, generating a unique set of permission adaptation tags for each screen device that corresponds one-to-one with permission level, geographical boundary, device type, and operation type. All device permission adaptation tag sets are uniquely bound to their corresponding screen control information, constructing a global screen permission tag index library. The system obtains the defined control permission scope for the account, extracts all parameters corresponding to the permission level, geographical coverage boundary, operable device type, and executable operation type, and generates an account permission matching tag set that perfectly matches the permission adaptation tag rules. Based on the account permission matching tag set, a global batch matching search is performed in the global screen permission tag index library, extracting the bound screen control information corresponding to screen devices with perfectly matching tag sets, forming the screen control information within the control permission scope. All device information that fails tag matching is fully filtered and intercepted. After completing the global tag matching and filtering, the screen control information within the control permission scope is structured according to preset hierarchical aggregation rules, and the hierarchical classification and visualization of the screen control information within the control permission scope is presented through a front-end interactive interface. Traditional public screen permission filtering and control models cannot adapt to the batch matching needs of multi-dimensional permission attributes. Permission filtering often suffers from inaccurate matching and low filtering efficiency. For example, with hundreds of public safety screens on the platform, if an account needs to filter devices within its own control permissions, the original model can only check the permission level, geographical boundaries, and device type one by one. It cannot complete multi-dimensional matching in batches, which leads to the filtering of unauthorized devices and the omission of compliant devices. Therefore, it can only rely on manual verification of permissions and device filtering, which is not only inefficient but also fails to achieve unified and efficient management of the platform. This technical solution, through the batch matching method of the above-mentioned full-domain tag index, can automatically complete the batch matching and filtering of multi-dimensional permission attributes. It solves the problems of inaccurate matching and low efficiency of traditional permission filtering and filtering, and also solves the problem of low efficiency caused by manual verification. It realizes unified automated permission filtering and control on the platform side, which significantly improves the accuracy, efficiency, and overall management efficiency of public safety screen permission filtering.

[0058] Furthermore, the platform pre-builds a global screen permission tag index library. For a district-level management operator account, it generates a set of account permission matching tags for its own permission level, geographical boundaries, and operable device types. It performs batch matching and retrieval in the index library, filters and blocks mismatched devices, extracts the management information of 126 matching screens, completes the structured processing, and presents it in a hierarchical and categorized visual presentation through the front-end interface.

[0059] For example, refer to Figure 3 and Figure 4 , Figure 3 This is a hierarchical geographic control map for this application. Figure 4This is a list of screen devices for this application. In a public screen management system in a certain district, operators log in using a street administrator account. After the system performs a full-dimensional legality verification of the submitted account password and facial recognition two-factor authentication information, it generates an identity credential uniquely bound to the account, with embedded permission verification fields and an encrypted timestamp. Based on the generated identity credential, the system initiates a permission matching request in the preset permission management database. After completing identity decryption verification, anti-counterfeiting verification, and identity consistency verification, the system matches the hierarchical management permissions corresponding to the account as street-level management permissions, which can perform operations such as viewing device status, remote on / off control, and content delivery review. At the same time, the corresponding geographical jurisdiction boundary is the entire geographical area of ​​the three communities under the street's jurisdiction. Subsequently, the system, based on the account's login location as the street office's internal network environment, extracted the login location influencing factors as a trusted internal network environment and regular login during legal working hours. Following a preset weighting rule, a login location weight of 1.2 was generated. Simultaneously, based on the environmental influencing factors of the 10 public screens to be managed within this geographical jurisdiction boundary—2 located in densely populated urban main roads, 5 in community entrances / exits, and 3 in commercial districts—corresponding influencing factor weights of 1.3, 1.1, and 1.2 were generated respectively, according to the environmental influence weighting rule. The login location weight and the influencing factor weights of each screen were then combined with a preset 6:4 weighting ratio to perform a fusion calculation, generating the corresponding environmental weight for each screen. Finally, the account's hierarchical management permissions and geographical jurisdiction boundary were weighted item by item with the environmental weights of each screen to generate the weighted hierarchical permissions and weighted geographical boundaries for each screen.According to the preset permission scope determination rules, the system performs a pre-verification of permission scope conflicts between the weighted hierarchical permissions corresponding to all single screens and the weighted geographical boundaries. After eliminating the permission cross-conflicts between two screens that cross community boundaries, the system finally determines that the account's management permission scope is 10 public screens within 3 communities under the jurisdiction of the street, and can perform full compliance management operations at the corresponding street level. Subsequently, based on the account's management permission scope, the system performs a full-dimensional compliance matching verification with each device as the smallest unit from the full screen information of 126 screens covering the entire district stored in the system. This verification checks whether the geographical distribution of the device falls within the management geographical boundary and whether the device management level matches the street level. The system checks whether the permission threshold and device operation type comply with account permission constraints. All information for devices that pass all checks is included in the compliant screen management information set. Finally, it filters out the full screen management information for 10 screens falling within the management permission range. The system displays this screen management information through the front-end interface of the public screen management system. The top of the front-end interface features a top navigation bar with device map, device ledger, device alarms, control records, and statistical analysis. The left sidebar includes function menus for device map, device management, statistical analysis, system management, and organization management. The 10 screens are first visualized on the device map page using an electronic map. The system displays the geographical distribution of the screens. The upper right corner of the page simultaneously shows statistical data categorized as follows: all devices, powered, powered off, and malfunctioning. There are 8 powered devices, 2 powered off, and 2 malfunctioning devices. The device ledger page also presents a list of all 10 devices, including their serial number, name, model, code, organization, detailed address, power, IoT status, power-on status, and access time. The top of the page displays the full status data for all 10 devices: 8 online, 0 offline, 2 faulty, 8 powered, and 2 powered off. The left side of the page features a searchable administrative tree structure filter for device areas, allowing operators to easily filter devices by community level. Simultaneously, the system synchronizes the filtered compliant screen management information to the device alarm, control record, and statistical analysis modules, providing full functionality for viewing device alarm information, tracing historical control records, and analyzing device operation data within the corresponding permission scope. The page also includes search, expand, reset, and add buttons to meet the device management operation needs within the account's compliant scope.

[0060] By generating a unique identity credential after logging in with an account, matching hierarchical control permissions with geographical jurisdiction boundaries, and combining environmental weights to accurately determine the scope of account control permissions, the problem of insufficient granularity of permission control, high risk of unauthorized access, and ambiguous device control boundaries in the field of public safety screen control has been solved, improving the compliance of screen control permissions, ease of operation, and centralized management efficiency.

[0061] Based on any of the above embodiments, in Embodiment 3 of this application, step A12 includes steps B11 to B15: Step B11: Based on the login location of the account and the factors influencing the login location, generate the login location weight according to the weighting rules.

[0062] In this embodiment, the login geolocation of an account refers to the complete spatial location information of the login terminal, including its actual physical location, administrative jurisdiction, and network access area, obtained by the system through compliant positioning methods when the account completes the login operation. Login location influencing factors refer to those directly related to the account's login geolocation, including sensitive information, restricted information, and regional promotional focus of the login area. Weighting rules refer to the system's pre-defined standardized execution guidelines that assign corresponding weighting coefficients based on the degree of influence of each environmental influencing factor, clarify the weighting calculation logic, boundary constraints, and anomaly correction rules. Login location weight refers to a quantitative adaptation coefficient calculated according to the weighting rules based on the account's login geolocation and corresponding environmental influencing factors, used to adapt and correct account control permissions and jurisdictional boundaries.

[0063] As an optional implementation, the login geolocation corresponding to the account's login operation is obtained, the administrative jurisdiction corresponding to this login geolocation is determined, and the login location influencing factors within this administrative jurisdiction are extracted. According to the control priorities specified in the weighting rules, the login location influencing factors are divided into three priority levels: sensitive control information, regional control restriction information, and regional publicity and guidance information. Following the control priority from high to low, the highest priority sensitive control information undergoes compliance verification and attribute matching. The matched sensitive control information is then assigned the highest-level weighting coefficient in the weighting rules, completing the first-level weight calculation and generating a basic weight benchmark value. Next, the second-priority regional control restriction information undergoes compliance verification and attribute matching. The matched regional control restriction information is then assigned the corresponding medium-level weighting coefficient in the weighting rules, completing the second-level weight calculation based on the basic weight benchmark value to generate an intermediate weight value. Finally, the third-priority regional publicity and guidance information undergoes compliance verification and attribute matching. The matched regional publicity and guidance information is then assigned the corresponding basic-level weighting coefficient in the weighting rules, completing the third-level weight calculation based on the intermediate weight value to generate the initial login location weight. According to the preset upper and lower limit constraints and compliance verification rules in the weight addition rules, the initial login location weight is checked for boundaries and anomalies are corrected, and the final login location weight is determined.

[0064] As an alternative implementation method, the system collects the login location influencing factors within the administrative jurisdiction of the account's login geographic location, and performs attribute analysis on three types of environmental impact factors: sensitive control information, regional control restriction information, and regional publicity guidance information. Based on the association matching rules explicitly defined in the weighting rules, the system performs cross-correlation matching among the three types of environmental impact factors, identifying the superimposed constraint association between sensitive control information and regional control restriction information, the adaptive association between regional control restriction information and regional publicity guidance information, and the mutually exclusive association between sensitive control information and regional publicity guidance information. This constructs an association coupling matrix for environmental impact factors. Based on the basic weight coefficients of the three types of environmental impact factors preset in the weighting rules, and combined with the correlation degree between each factor in the association coupling matrix, the system performs coupling correction on the weight coefficients of each environmental impact factor, generating the corresponding coupling correction weight coefficients for each environmental impact factor. The coupling correction weight coefficients corresponding to all environmental impact factors are then fully integrated and calculated to generate the initial login location weight. Following the compliance verification rules and boundary constraint rules preset in the weighting rules, the initial login location weight undergoes full-dimensional compliance verification and outlier correction, generating a login location weight that is fully adapted to the login geographic location and all environmental impact factors. The traditional one-time push mode for public screen content cannot adapt to the constraints of multi-dimensional environmental factors affecting the login location. This often leads to deviations in content control and compliance. For example, all public safety screens in a province might be uniformly pushing promotional information for a certain entertainment event, but the administrative region where the account is logged in has sensitive control requirements and regional restrictions on this type of information. Furthermore, the current regional focus is on prioritizing public service announcements related to production safety, making this information unsuitable for that region. The original one-time push control model cannot adapt to the multi-dimensional control constraints of that region, resulting in the inability to accurately avoid that region when controlling the information, leading to non-compliant content delivery and mismatched promotional orientation. Therefore, manual adaptation and debugging for each region is necessary, which is not only inefficient but also fails to achieve unified platform control. This new technical solution, through the aforementioned cross-coupled weight calculation method, can automatically complete the correlation adaptation and weight correction of multi-dimensional environmental factors. This solves the problem of one-time push not adapting to multi-dimensional environmental constraints and poor control adaptability, while also addressing the inefficiency of manual debugging. It achieves unified automated control on the platform side, significantly improving the compliance, accuracy, and overall efficiency of public safety screen control.

[0065] Furthermore, if an operator's account is logged in from an administrative region A, the platform performs the following operations: It collects factors influencing the login location in this region, and analyzes three types of environmental factors: sensitive control information prohibiting the placement of content related to major sporting events; regional control restrictions on screen brightness and placement duration on main roads at night; and regional publicity priorities for public service announcements related to the creation of a civilized city. It matches the cross-correlation of these three factors according to weighted rules, identifying the superimposed constraint relationship between sensitive control and regional restrictions (correlation degree 0.82), the adaptation relationship between regional restrictions and publicity priorities (correlation degree 0.76), and the absence of mutually exclusive relationships between sensitive control and publicity priorities (correlation degree 0.1), thus constructing a correlation coupling matrix. Based on preset base weights (sensitive control 0.4, regional restrictions 0.35, publicity priorities 0.25), and combining the correlation degree, it performs coupling correction, generating corrected weights of 0.42, 0.36, and 0.22. A full-domain fusion calculation generates an initial login location weight of 0.85. After compliance verification and boundary correction, a final login location weight of 0.85 is generated to be adapted to this login location.

[0066] Step B12: Based on the environmental impact factors of the scene in which each screen to be managed is located, generate the weights of the impact factors according to the environmental impact additional rules.

[0067] In this embodiment, the screen to be managed refers to a public screen device that has been connected to the public screen management system, has remote IoT management capabilities, and is included in the account's jurisdiction. The scenario of the screen to be managed refers to the complete set of scenario attributes corresponding to the physical space environment, administrative jurisdiction, personnel coverage, public safety management level, and functional positioning of a single screen. Environmental influencing factors refer to activities, pedestrian traffic, and recent events related to the surrounding environment of the screen to be managed. Environmental influence rules refer to standardized execution guidelines pre-set by the system that clearly define the influence level classification, weight coefficient matching standards, calculation execution logic, compliance verification boundaries, and anomaly correction rules for each scenario's environmental influencing factors. Influence factor weights refer to quantitative adaptation coefficients calculated strictly according to the environmental influence rules based on all environmental influencing factors in the scenario of a single screen to be managed, used to adapt and correct the account's management authority boundaries and management priority for that screen.

[0068] As an optional implementation method, environmental influencing factors corresponding to the scene where the screen to be managed is located are extracted and ranked according to the temporal influence priority specified in the preset environmental influence addition rules. The scene environmental influencing factors are divided into three temporal priority levels: real-time dynamic factors related to real-time pedestrian flow and on-site activities, medium-term influencing factors related to recent surrounding events, and long-term basic factors related to normalized personnel activities in the scene. Following the temporal influence priority from high to low, the highest priority real-time dynamic factors are first matched for attribute matching and compliance verification. For each matched real-time dynamic factor, the highest level weight addition coefficient in the environmental influence addition rules is assigned. This completes the first-level weight calculation to generate a core weight benchmark value. Next, the second-priority medium-term influencing factors are matched for attribute matching and compliance verification. For each matched medium-term influencing factor, the corresponding medium-level weight addition coefficient in the environmental influence addition rules is assigned. Based on the core weight benchmark value, the second-level weight addition calculation is completed to generate an intermediate weight value. Finally, the third-priority long-term basic factors are matched for attribute matching and compliance verification. For each matched long-term basic factor, the corresponding basic level weight addition coefficient in the environmental influence addition rules is assigned. Based on the intermediate weight value, the third-level weight addition calculation is completed to generate the initial influence factor weight. In accordance with the pre-set upper and lower limit constraints and compliance verification rules in the supplementary rules for environmental impact, the initial impact factor weights are subjected to boundary verification and anomaly correction, and impact factor weights adapted to the scene in which the screen to be managed is located are generated. The traditional one-time push mode of public screen content cannot adapt to the dynamic constraints of multi-time-series environmental factors influencing the scene of a single screen to be managed. The pushed content often suffers from insufficient scene adaptability and deviations in management compliance. For example, all public safety screens in the city are uniformly pushing nighttime commercial promotion information. However, in the core business district of the city where the screen to be managed is located, the real-time dynamic factors are that the flow of people during the evening peak hours exceeds the control threshold and an emergency evacuation drill is being carried out on site. The medium-term influencing factors are that a large-scale municipal exhibition will be held in the surrounding area within 3 days, which will require temporary content control. The long-term basic factor is that the business district is a key location for the creation of a civilized city and has the normalized control requirement of prioritizing public welfare publicity. The commercial promotion information is not suitable for the screen to be displayed at this time. The original one-time push management mode of the whole area cannot adapt to the dynamic environmental constraints of the screen according to the time priority. This will lead to the inability to accurately adapt to the real-time changes of the single screen scene when managing the information, resulting in problems such as non-compliant content delivery, low scene adaptability, and untimely emergency management response. Therefore, it is necessary to rely on manual one-by-one scene adaptation and debugging for each screen.This solution, through the aforementioned hierarchical weight calculation method based on the priority of time-series influence, can automatically complete the attribute matching, compliance verification, and hierarchical weight addition calculation of environmental influencing factors at different time-series levels. It solves the problems of one-time push streaming being unable to adapt to multi-time-series dynamic environmental constraints and poor adaptability of single-screen management. At the same time, it solves the problems of low management efficiency and untimely emergency response caused by manual debugging. It achieves unified, automated, and precise management on the platform side, and significantly improves the scenario adaptability, emergency response speed, and overall management efficiency of public safety screen management.

[0069] Furthermore, a certain screen to be controlled is a PIS-LED65 public safety screen on the main road of a core business district in a certain city. The platform performs the following operations: extract the environmental impact factors corresponding to the business district scene where the screen is located, and divide the scene environmental impact factors into three time priority levels according to the time priority of the preset environmental impact additional rules: real-time dynamic factors of real-time traffic flow and on-site emergency drills, medium-term impact factors of temporary control of municipal exhibitions in the surrounding area within 3 days, and long-term basic factors of priority of public welfare publicity for the creation of civilized cities in the business district; according to the time priority from high to low, the highest priority real-time dynamic factors are first matched and verified for compliance. For the two real-time dynamic factors of excessive traffic flow during the evening peak and on-site emergency drills that have passed the matching, the highest level weight additional coefficient of 0.6 in the environmental impact additional rules is matched, and the first level weight calculation is completed to generate the core weight benchmark value of 0.6. Next, attribute matching and compliance verification were performed on the second priority mid-term influencing factors. A medium-level weighting coefficient of 0.25 was assigned to the matched temporary control requirements for the exhibition. Based on the core weight benchmark value, the second-level weighting calculation was completed to generate an intermediate weight value of 0.75. Subsequently, attribute matching and compliance verification were performed on the third priority long-term fundamental factors. A basic-level weighting coefficient of 0.15 was assigned to the matched public welfare promotion priority normalization requirements. Based on the intermediate weight value, the third-level weighting calculation was completed to generate an initial impact factor weight of 0.9. In accordance with the preset upper and lower weight limits of 0-1 and the compliance verification rules in the environmental impact additional rules, the initial impact factor weight was boundary-verified to confirm that there were no outliers and no correction was needed. Finally, an impact factor weight of 0.9 was generated that is fully adapted to the business district scenario where the screen to be controlled is located.

[0070] Step B13: Combine the landing location weight and the influence factor weight with a preset weight ratio to calculate the environmental weight.

[0071] In this embodiment, the preset weight ratio refers to the standardized execution criteria pre-set by the system, which clearly defines the distribution of the influence of the login location weight and the influence factor weight in the fusion calculation, the fusion execution rules, and the compliance verification boundaries. It is the sole basis for compliance calculation of the fusion of the two weights. The environmental weight refers to the comprehensive adaptation coefficient generated after the login location weight and the influence factor weight are fused and calculated according to the preset rules. It is used to make weighted corrections to hierarchical control authority and geographical jurisdiction boundaries.

[0072] As an optional implementation method, the generated influence factor weights corresponding to the screen to be managed are obtained. The basic influence proportion of the login location weight, the basic influence proportion of the influence factor weight, and the basic fusion rules, which are explicitly defined in the preset weight ratios, are extracted. First, the login location weight undergoes compliance verification to confirm that it meets the preset upper and lower weight limits. Then, the influence factor weights of the screen undergo compliance verification to confirm that they meet the preset upper and lower weight limits. According to the basic fusion rules, the verified login location weight is weighted according to its basic influence proportion, and the verified influence factor weights are weighted according to their basic influence proportions. The results of the two weighting processes are then fused to generate the initial environmental weight. According to the preset compliance verification rules, boundary verification and outlier correction are performed on the initial environmental weight, ultimately generating an environmental weight uniquely corresponding to the screen to be managed.

[0073] Step B14: The hierarchical control permissions and the geographical control boundaries are respectively weighted by the environmental weights to obtain weighted hierarchical permissions and weighted geographical boundaries.

[0074] In this embodiment, weighted hierarchical permissions refer to the dynamically adjusted hierarchical management permissions generated after performing compliant weighted calculations on basic hierarchical management permissions and environmental weights, adapting to the login location and screen scene environment. Weighted geographic boundaries refer to the dynamically adjusted geographic jurisdiction boundaries generated after performing compliant weighted calculations on basic geographic management boundaries and environmental weights, adapting to the login location and screen scene environment.

[0075] As an optional implementation, a unique environmental weight corresponding to the screen to be managed is obtained. First, the basic hierarchical management permissions are verified for compliance to confirm that they conform to the system's preset permission management rules. The verified basic hierarchical management permissions are then weighted item by item with the environmental weight corresponding to the screen. Based on the adaptation coefficient of the environmental weight, the operation type coverage, execution depth threshold, and approval level requirements of the hierarchical management permissions are adjusted. After completing the permission compliance verification, the weighted hierarchical permissions corresponding to the screen are generated. Next, the basic geographic management boundaries are verified for compliance to confirm that they conform to the system's preset spatial jurisdiction rules. The verified basic geographic management boundaries are then weighted item by item with the environmental weight corresponding to the screen. Based on the adaptation coefficient of the environmental weight, the spatial coverage, regional management granularity, and device affiliation determination rules of the geographic management boundaries are adjusted. After completing the boundary compliance verification, the weighted geographic boundary corresponding to the screen is generated.

[0076] Step B15: According to the permission scope determination rules, adjust the conflict between the weighted hierarchical permissions and the weighted geographical boundary permission scope to obtain the management permission scope of the account.

[0077] In this embodiment, the permission scope determination rule refers to the system's pre-set, standardized execution rules that clearly define the permission conflict identification standards, conflict priority ranking logic, conflict compliance adjustment criteria, full-process verification boundaries, and final permission scope generation specifications. Permission scope conflicts refer to contradictions that do not meet compliance control requirements, such as permission overlap, boundary overlap, unauthorized access risks, and rule mutual exclusion, that exist between weighted hierarchical permissions and weighted geographical boundaries, between weighted permissions corresponding to different target screens, and between the weighted adjusted permission boundaries and the system's basic control rules.

[0078] As an optional implementation, based on the weighted hierarchical permissions and weighted geographical boundaries of the target screen corresponding to the account, and sorted according to the device verification priority specified in the permission scope determination rules, taking a single screen to be managed as the smallest processing unit, the following are identified sequentially: internal adaptation conflicts between the weighted hierarchical permissions and weighted geographical boundaries of the screen; rule compliance conflicts between the screen's permission boundaries and the system's basic management rules; and boundary cross-conflicts between the screen and adjacent managed screens. According to the conflict priority specified in the permission scope determination rules, high-priority rule compliance conflicts are processed first, followed by medium-priority boundary cross-conflicts, and finally low-priority internal adaptation conflicts. For each identified conflict, the permission and boundary adaptation is adjusted according to the corresponding compliance adjustment logic in the permission scope determination rules. After adjustment, a closed-loop secondary verification is performed on the single screen. Once it is confirmed that there are no conflicts, the permission and boundary parameters of the screen are locked. After completing the conflict adjustment and closed-loop verification for each target screen, all locked permission and boundary parameters are integrated to generate the management permission scope corresponding to the account.

[0079] As an alternative implementation, based on the weighted hierarchical permissions and weighted geographical boundaries corresponding to the account, and according to the control level division standards clearly defined in the preset permission range determination rules, permissions and boundary parameters are divided into three progressive control levels: the system top-level rule layer, the regional cluster layer, and the single-device execution layer. First, for the system top-level rule layer, it verifies whether the full weighted hierarchical permissions and weighted geographical boundaries conform to the system's preset top-level control rules and permission red lines, identifies and adjusts system-wide rule conflicts and unauthorized access risks, and locks the account's top-level permission boundary framework after resolving top-level conflicts. Next, for the regional cluster layer, based on the locked top-level permission boundary framework, it verifies the weighted hierarchical permissions and weighted geographical boundaries corresponding to each regional cluster, identifies and adjusts cross-cluster boundary overlap conflicts, permission mutual exclusion conflicts, and jurisdictional overlap conflicts, and locks the permission boundary range of each regional cluster after resolving inter-cluster linkage conflicts. Finally, for the single-device execution layer, based on the permission boundary range locked by each cluster, the weighted hierarchical permissions and weighted geographical boundaries of each target screen within the cluster are verified. Adaptation conflicts and fine-grained deviations within a single device are identified and adjusted. After resolving single-device conflicts, the permission parameters of a single screen are locked. After completing the conflict adjustment at all levels, the control permission range corresponding to the account is generated. In the traditional unified control model for public screens across the entire domain, the lack of a layered and progressive permission boundary verification and conflict resolution mechanism often leads to problems such as cross-level unauthorized control, overlapping regional boundary conflicts, and single-device permission adaptation deviations. For example, a provincial platform might uniformly push commercial promotional information, but subordinate municipal areas have exclusive control permissions, and key screen locations have fine-grained control requirements. The original model cannot verify permissions and geographical boundaries layer by layer, leading to unauthorized pushes, cross-regional control conflicts, and non-compliant single-device deployments. Therefore, it can only rely on manual layer-by-layer permission verification and conflict resolution, which is not only inefficient but also fails to achieve unified and standardized control of the platform. This solution, through the aforementioned three-tiered progressive permission boundary verification and conflict resolution method, can automatically complete permission verification, conflict adjustment, and boundary locking at all levels. It solves the problems of traditional permission control lacking layering, untimely conflict resolution, and difficulty in controlling the risk of unauthorized access. At the same time, it solves the problem of low management efficiency caused by manual verification, realizes unified automated permission control on the platform side, and significantly improves the compliance, accuracy, and overall management efficiency of public safety screen permission control.

[0080] Furthermore, for a municipal-level public safety screen management operator account, the platform performs the following operations: Based on the account's weighted hierarchical permissions and weighted geographical boundaries, it is divided into three progressive management levels according to preset rules: the system top-level rule layer, the regional cluster layer, and the single-device execution layer. First, the top-level permissions are verified to comply with the system management rules and permission red lines. After resolving top-level conflicts, the municipal-level top-level permission boundary framework of the account is locked. Then, based on the top-level framework, the permissions and boundaries of the six district / county regional clusters under its jurisdiction are verified, resolving cross-cluster boundary overlaps and jurisdictional conflicts, and locking the permission boundary range of each cluster. Finally, based on the cluster range, the permission parameters of 126 target screens within the cluster are verified, resolving single-device adaptation conflicts, and locking the permission parameters of a single screen. After completing the conflict adjustment at all levels, the municipal-level overall management permission range corresponding to this account is generated.

[0081] For example, in the scenario of managing public safety screens, the account login geolocation is obtained as a fixed location on the office intranet. The influencing factors of the login location are extracted as follows: district-level publicity and management entity, trusted intranet security environment, login time is during working hours on a legal working day, the current publicity focus of the login location is public welfare publicity for the creation of a civilized city, and there is no sensitive control and restriction information. According to the preset weighting rules, compliance calculation is completed, and the login location weight corresponding to this account login is 1.25. Subsequently, for the 24 public safety screens to be managed within the initial geographical jurisdiction boundary of the account, the system extracts the environmental influencing factors of the scene where each screen is located. Among them, 8 screens are located in high-traffic scenes with an average daily traffic of 20,000 people on the main urban road, 10 screens are located in regular scenes with an average daily traffic of 3,000 people at the entrances and exits of residential communities, and 6 screens are located in medium-high traffic scenes with an average daily traffic of 15,000 people in the core business district square. At the same time, it is confirmed that there are no major sudden control events in the vicinity of all screens recently. According to the preset environmental influence additional rules, compliance calculation is completed, and the influencing factor weights corresponding to the three types of screens are generated as 1.4, 1.05, and 1.3 respectively. The system combines the generated login location weight with the influence factor weights corresponding to each screen, using a preset 5:5 fixed weight ratio, to generate an environmental weight of 1.325 for 8 main road screens, 1.15 for 10 community screens, and 1.275 for 6 commercial district screens. The system then performs a weighted calculation on the account's district-level basic hierarchical control permissions and overall geographic control boundaries, along with the environmental weights for each screen, to obtain the corresponding weighted hierarchical permissions (main road and commercial district screens have full access to public service content and remote start / stop control permissions, while community screens only have basic public service content access permissions) and weighted geographic boundaries (locking in the precise administrative jurisdiction and spatial coverage of the 24 screens). Finally, strictly following the preset permission scope determination rules, the system identifies and adjusts to eliminate permission conflicts between two screens crossing street boundaries. After completing a closed-loop compliance verification of all permissions and boundaries, the system ultimately determines the account's control permission scope as the hierarchical control permissions and precise geographic jurisdiction boundaries for the 24 corresponding public safety screens within the district.

[0082] By combining the dual-dimensional environmental factors of account login location and screen scene to generate adaptation weights, and then merging and calculating the environmental weights to complete the weighted adaptation of hierarchical control permissions and geographical control boundaries, the problem of insufficient permission granularity and control-permission conflicts in the field of public safety screen control is solved, thereby improving the accuracy, compliance and scene adaptability of hierarchical control of public safety screens.

[0083] Based on any of the above embodiments, in Embodiment 4 of this application, step S20 includes steps C11 to C13: Step C11: In response to the screen control request, the priority of the screen control request is calculated by weighting according to the control type of the screen control request, the corresponding screen state and the security level of the scene in which the screen is located, according to the priority weighting rules.

[0084] In this embodiment, the control type refers to the category of control operation corresponding to the control request, which is the core dimension for distinguishing control operation attributes and allocating basic weights. Screen status refers to the real-time operating conditions, online status, and task execution status of the target screen when it receives the request. The security level of the screen's environment refers to the classification identifier of the public safety control level and emergency control requirement level corresponding to the target screen's deployment environment.

[0085] As an optional implementation, in response to a received screen control request, the control type, target screen state, and security level of the target screen's environment are extracted, and then sorted according to the dimensions specified in the preset priority weighting rules. First, basic weight matching is performed on the control type; then, adaptability verification and weight correction are completed for the screen state; subsequently, compliance verification and weight addition are performed for the scene security level. After completing the weighted calculation of each of the three dimensions, an initial priority is generated. Compliance verification and boundary correction are then performed according to the priority weighting rule's grading standard to generate the priority of the screen control request.

[0086] Step C12: Based on the priority of the screen control request, compare its priority with that of conflicting screen control requests to obtain the priority comparison result.

[0087] In this embodiment, conflicting screen control requests refer to other screen control requests that are pending execution but cannot be executed synchronously and in compliance with regulations, targeting the same screen as the current request, having mutually exclusive execution times, conflicting operation content, or conflicting control resource usage. The priority comparison result refers to a standardized compliance result generated after completing a full-dimensional priority comparison, clearly defining the priority ranking, conflict handling rules, and execution permission determination conclusions of the current request and conflicting requests.

[0088] As an optional implementation, the priority and hierarchical identifiers corresponding to screen control requests are obtained. Based on the screen identifiers of the screen control requests, all pending screen control requests for the target screen within the system are matched and identified. Each request is verified to identify screen control requests that conflict with the current request in terms of execution sequence, operation content, or resource usage. The priority values ​​and hierarchical identifiers corresponding to all conflicting control requests are extracted. According to preset priority comparison rules, the priority of the current request is compared with the priority of each conflicting request, and the compliance boundaries of the priority hierarchy are verified. A priority comparison result clearly defining the priority ranking and conflict handling permissions of the current request and all conflicting requests is generated.

[0089] As another optional implementation, based on the target screen corresponding to the screen control request, it is determined that there are regional screen control requests to be executed on the target screen, the priority of the screen control request and the regional screen control requests to be executed are compared, and the priority comparison result is determined according to the size of the two priorities.

[0090] Step C13: After adjusting the screen control request based on the priority comparison result, generate the screen control strategy according to the adjusted screen control request and its corresponding execution sequence.

[0091] In this embodiment, execution timing refers to standardized timing parameters, which are determined based on priority sorting and conflict resolution results, and include the execution order, time nodes, and execution interval rules of the operations corresponding to the control request.

[0092] As an optional implementation, based on the priority comparison results, the priority of the current screen control request and all conflicting requests is determined item by item. If the priority of the current screen control request is higher than that of all conflicting requests, the full control content and execution requirements of the current request are retained, and the execution sequence of all conflicting requests is adjusted until the current request is completed. If the priority of the current request is lower than that of the conflicting requests, the execution sequence of the current request is adjusted until all high-priority conflicting requests are completed, and the compliance and executability of the adjusted request are verified. The adjusted screen control request and its corresponding execution sequence are locked, and a screen control strategy including control operation content and execution nodes is generated according to preset standardized execution rules.

[0093] For example, in a scenario involving the control of public safety screens, operators from the Municipal Emergency Management Bureau, within their legal control authority, initiated a screen control request for the deployment of emergency meteorological disaster warnings on 12 public safety screens along main roads in the main urban area. The system responded to this request, identifying the control type as emergency control, the target screens' real-time status as all online and operating normally, and the safety level of the densely populated main road where the screens are located as Level 1. According to preset priority weighting rules, the control type was assigned 60% weight, the screen status 15% weight, and the scene safety level 25% weight, resulting in a weighted priority of 98 points (Level 1, the highest priority). Simultaneously, the system identified three pending routine public service announcement control requests for the same 12 screens, extracting their corresponding priorities of 62, 58, and 65 points (Level 3 routine priority), respectively. A priority comparison was then performed between this emergency request and the three conflicting requests, revealing that this request had a significantly higher priority than all the conflicting requests. Based on the comparison results, the full content of this emergency control request is retained. The execution sequence of the three conflicting regular requests is adjusted until the emergency request is completed. The adjusted control request and execution sequence are locked, and a screen control strategy is generated that includes the execution nodes of the entire process of warning content delivery and closed-loop verification requirements.

[0094] By using multi-dimensional weighted calculation to prioritize control requests, compare conflicting request priorities, and adjust request execution sequence based on comparison results in compliance with regulations, the problem of multi-source request execution conflicts in public safety screen management has been solved, improving the emergency response efficiency, execution orderliness, and compliance of public safety screen management.

[0095] Based on any of the above embodiments, in Embodiment 5 of this application, step S30 includes steps D11 to D14: Step D11: Analyze the screen control strategy and combine it with the operating parameters of the target screen to obtain control parameters.

[0096] In this embodiment, the operating parameters of the target screen refer to the real-time operating conditions, hardware attributes, communication specifications, power thresholds, and current task load of the target screen terminal. The control parameters refer to a standardized set of operating parameters generated after policy parsing and adaptation and correction of the screen operating parameters, matching the target screen's execution capabilities and directly usable for generating control commands.

[0097] As an optional implementation, the control operation objectives, execution content, timing requirements, and compliance constraints in the screen control strategy are parsed. After compliance verification of the parsed content, initial control parameters are generated. Simultaneously, the operating parameters of the corresponding target screen are acquired, and compliance verification and attribute matching are performed on the target screen's operating parameters. Based on the screen's operating parameters, the initial control parameters are adjusted item by item for adaptation. The matching degree between the adjusted control parameters and the target screen's operating capabilities is verified, and control parameters adapted to the target screen are generated.

[0098] Step D12: Based on the status information of the target screen corresponding to the screen control strategy, determine the power type and control link attribute of the target screen.

[0099] In this embodiment, the power type of the target screen refers to the device power supply category classified according to the screen power supply mode, rated power range, and operating power consumption level, used to distinguish the power adaptation method during control. The control link attribute refers to the communication characteristic category of the communication protocol type, transmission rate, link stability, and connection method between the target screen and the control terminal, used to determine the adaptation method for command transmission.

[0100] As an optional implementation, the status information of the target screen corresponding to the screen control strategy is retrieved. Power supply mode, real-time power consumption, and rated load parameters are extracted according to preset power determination rules. Power type is determined item by item through feature matching, and the classification result is locked. Then, communication protocol, transmission quality, and connection method parameters are extracted according to preset link determination rules. Control link attributes are determined item by item through feature matching, and the classification result is locked. Consistency verification is performed on the two determination results to determine the power type and control link attributes of the target screen.

[0101] Step D13: Based on the power type of the target screen and the control link attribute, verify the adaptability of the control parameters and adjust them to obtain the adaptation parameters.

[0102] In this embodiment, the control link attribute refers to the communication transmission characteristics constituted by the communication protocol type, transmission bandwidth limit, and link response characteristics used by the target screen. Control parameters refer to the initial set of control operation parameters generated by parsing the screen control strategy and combining it with the screen operating parameters.

[0103] As an optional implementation, power thresholds, load constraints, and power supply adaptation rules are extracted based on the power type of the target screen. Adaptability checks are then performed on each power-related configuration item within the control parameters to identify abnormal parameters that exceed hardware capacity or violate power supply constraints, and these are corrected according to the power type specification. Next, protocol specifications, transmission constraints, and response thresholds are extracted based on the control link attributes. Adaptability checks are then performed on each transmission-related configuration item within the control parameters to identify abnormal parameters that do not meet link transmission requirements or exceed link capacity, and these are corrected according to the link attribute specification to obtain the adaptation parameters.

[0104] Step D14: Map the adaptation parameters into control commands that conform to the target screen terminal communication according to the execution encoding mapping rules.

[0105] In this embodiment, the encoding mapping rule is a system-preset standardized conversion guideline that converts adaptation parameters into a target screen-recognizable encoding format, instruction fields, and data structures. Target screen terminal communication refers to the communication protocols, instruction parsing formats, and data transmission specifications supported by the target screen hardware.

[0106] As an optional implementation method, all independent control operation items within the adaptation parameters are extracted. According to the one-to-one encoding correspondence of single parameters preset in the execution encoding mapping rules, each control operation item is mapped to the corresponding terminal instruction code. The target screen terminal communication format is verified for each group of codes to confirm that the encoding fields and data lengths comply with the terminal parsing specifications. Incompatible encoding segments are removed and the corresponding compliant codes are re-matched. All verified independent instruction codes are combined in an orderly manner according to the data frame sorting requirements of terminal communication to generate complete control instructions.

[0107] For example, in the scenario of controlling a public safety screen, the target screen is a PIS-LED65 outdoor public safety screen. The screen control strategy for emergency warning deployment is analyzed. Combined with the target screen's operating parameters of 60Hz refresh rate, brightness adjustment range of 0-100%, and playback frame rate of 25fps, control parameters of 80% brightness, 3 loop playbacks of the warning, and 60% volume are obtained. Based on the target screen's online steady-state operation, rated power of 220W, real-time power consumption of 180W, and 4G full network communication status information corresponding to this strategy, the power type is determined to be medium-power constant supply type, and the control link attribute is 4G wireless high-latency link. The control parameters are verified according to the power type and link attribute. It is found that the volume of 60% exceeds the audio load threshold and the high-latency link does not support the original frame rate. The adjusted parameters are obtained as follows: brightness of 75%, loop playback of 3 times, volume of 45%, and frame rate of 20fps. The adapted parameters are encoded and mapped according to the GB / T 28181 encoding mapping rules to match the hexadecimal control instructions for the screen terminal communication.

[0108] By using strategy parsing, parameter generation, power and link verification adaptation, and instruction encoding mapping, the problems of hardware incompatibility, transmission failure, and power overload of public safety screen control instructions have been solved, thereby improving the success rate of instruction issuance and execution stability.

[0109] Based on any of the above embodiments, in Embodiment Six of this application, step S40 includes steps E11 to E13: E11. Based on the execution timing of the screen control request and the corresponding link delay, determine the sending timing of the control command corresponding to the screen control request.

[0110] In this embodiment, link latency refers to the real-time transmission delay and response latency of the control communication link between the server and the target screen terminal, which are the core basis for transmission timing correction. The transmission timing of control commands refers to the standardized scheduling parameters of the order in which the server issues control commands, the issuance time nodes, and the issuance intervals.

[0111] As an optional implementation, the execution sequence corresponding to the screen control request is obtained, and the execution time node and execution interval parameters are extracted from the execution sequence. The link delay parameters of the control link corresponding to the target screen for the screen control request are also obtained. According to the timing correction rules, the execution time node is moved forward to adapt and correct the link delay, resulting in the control command issuance time node. The execution interval parameter is then adjusted in conjunction with the link delay fluctuation correction rules to obtain the control command issuance interval parameter. The adjusted issuance time node and issuance interval are then verified for compliance, confirming that they conform to the system's scheduling boundaries and constraints. After correcting outliers, the sending sequence of the control command corresponding to the screen control request is determined.

[0112] Step E12: Based on the transmission timing, the control commands are sent sequentially to the corresponding target screens via the IoT communication service.

[0113] In this embodiment, IoT communication service refers to the standardized IoT communication support service deployed by the system for establishing communication connections and completing data transmission between the server and public screen terminals, and is the core carrier of command transmission.

[0114] As an optional implementation, the explicit command issuance order, issuance time node, and issuance interval parameters are extracted from the transmission sequence. Each control command is retrieved sequentially according to the issuance order. When the issuance time node of the corresponding command is reached, a communication connection is established with the corresponding target screen via IoT communication service. The control command is then encrypted and encapsulated before being sent to the target screen, and confirmation of the command's transmission status is obtained. After confirming successful transmission, the system waits for the corresponding issuance interval until the issuance time node of the next command is reached. This transmission and confirmation process is repeated until all control commands have been sent, completing the full-process transmission compliance verification.

[0115] Step E13: Receive terminal receipt information and instruction execution status transmitted back from the target screen, so as to control the target screen to complete the content of the control instruction.

[0116] In this embodiment, terminal receipt information refers to standardized confirmation information returned by the target screen terminal to the server after receiving the control command, confirming that the command has been successfully received. It is the core feedback of the command reception status. Command execution status refers to standardized status information returned by the target screen terminal to the server after completing the execution of the control command, describing the command execution result, execution progress, and execution exception information.

[0117] As an optional implementation, the system receives terminal receipt information from the target screen, performs identity and compliance verification on the terminal receipt information, confirms that the terminal receipt information is a legitimate feedback from the corresponding target screen, and confirms that the control command has been successfully received by the target screen. Subsequently, it receives the command execution status from the target screen, performs identity and compliance verification on the execution status, confirms that the status is a legitimate feedback from the corresponding target screen, and compares the execution status with the content of the control command item by item to confirm that the target screen has completed all execution content of the control command. If there are any incomplete execution items, the corresponding control operation is triggered until all execution items are completed, thus completing the closed-loop control verification.

[0118] For example, in a public safety screen control scenario in the main urban area of ​​a city, the Municipal Emergency Management Bureau initiated a meteorological early warning control request for 12 PIS-LED65 public safety screens on main roads. The execution sequence of this request was to start the early warning deployment at 14:30:00. The real-time delays of the 4G control link for the 12 screens were 120ms, 135ms, 118ms, 142ms, 127ms, 131ms, 125ms, 138ms, 122ms, 133ms, 129ms, and 136ms, respectively. After link delay correction, the control command sending sequence was determined to be to start sending the commands sequentially at 14:29:59.87, with a single command interval of 10ms. The 12 control commands were sent in batches in parallel through the IoT communication service according to the sending sequence. Within 100ms after the sending was completed, the terminal acknowledgment information and command execution status transmitted back from the 12 screens were received successively, confirming that all commands were executed normally.

[0119] By adapting the transmission timing to link delay, issuing instructions in sequence, and implementing closed-loop control of receipts, the problems of instruction timing deviation and uncontrollable execution status in public safety screen management have been solved, thereby improving the accuracy of instruction issuance and the closed-loop control capability.

[0120] Based on any of the above embodiments, in Embodiment 7 of this application, after step S10, steps F11 to F13 are further included: Step F11: Based on the screen management information within the scope of the management authority, the devices are hierarchically classified according to the administrative tree structure to obtain list-style screen device information and real-time online / offline status data.

[0121] In this embodiment, the administrative tree structure refers to a standardized tree-shaped classification framework based on administrative jurisdiction levels and possessing hierarchical subordinate relationships. Device hierarchical classification refers to a standardized process of classifying and grouping target screen devices layer by layer according to the hierarchical subordinate relationships of the administrative tree structure. List-style screen device information refers to a standardized data set of basic attributes and attribution information of the target screens, generated after classification and presented in list form. Real-time online / offline status data refers to real-time feedback data on the current online / offline operating status of the target screens, generated synchronously after classification.

[0122] As an optional implementation, all screen control information within the scope of control authority is extracted, and the complete hierarchical nodes of the administrative tree structure are obtained. Starting from the root node at the top level of the administrative tree, each level node is traversed downwards. For each level node, the administrative jurisdiction corresponding to that node is extracted. Screen devices belonging to the node within the scope of control authority are classified and grouped. This process is repeated for all levels of nodes and devices. After completing the hierarchical classification of all devices, the grouped screen basic attribute information is organized into a list of screen device information, and the grouped screen real-time online / offline status information is organized into corresponding real-time online / offline status data.

[0123] As an alternative implementation, all screen management information within the scope of control authority is extracted, and the administrative affiliation attributes corresponding to all screens are extracted. Based on these administrative affiliation attributes, all screens are batch-clustered and grouped. Screens belonging to the same administrative level are grouped into the same cluster group. The complete hierarchical nodes of the preset administrative tree structure are obtained, and all cluster groups are batch-mapped and matched with the hierarchical nodes of the administrative tree, completing the hierarchical classification of all screens in one go. After classification, the basic attribute information of all grouped screens is batch-organized into a list-style screen device information, and the real-time online / offline status information of all grouped screens is batch-organized into corresponding real-time online / offline status data.

[0124] Step F12: Combine the list-style screen device information with the real-time online / offline status data, and generate screen health data by linking the status list according to multi-dimensional statistical rules.

[0125] In this embodiment, multi-dimensional statistical rules refer to standardized execution rules preset by the system that conduct statistical analysis from multiple dimensions such as device runtime, online stability, and failure frequency. The linked status list refers to standardized list data that carries all associated status information, generated after associating and integrating screen device information with real-time status data. Screen health data refers to standardized quantitative data that is quantified after multi-dimensional statistical analysis and used to characterize the target screen's operational health status and failure risk level.

[0126] As an optional implementation, the generated list-style screen device information and real-time online / offline status data are extracted. For each target screen, the basic device information and real-time status data corresponding to that target screen are extracted. According to preset multi-dimensional statistical rules, independent statistical analysis is performed on each dimension of the screen, including runtime, online stability, and failure frequency. The statistical results of all dimensions of the screen are then correlated and integrated to generate a linkage status list corresponding to that screen. Based on the full-dimensional statistical results of the linkage status list, quantitative calculations are performed to generate the health data corresponding to that screen. After processing all target screens, health data for all target screens is generated.

[0127] Step F13: Based on the screen health data, detect the device communication and working status of the screen, and trigger a graded alarm and archive historical alarm records when abnormalities occur.

[0128] In this embodiment, device communication status refers to the real-time operational status of the communication link connectivity and transmission stability between the target screen and the control terminal. Working status refers to the real-time operating condition of the target screen's own hardware operation and task execution. Tiered alarm refers to a standardized alarm mechanism that classifies alarms into different levels based on the severity of abnormal states and matches corresponding alarm handling rules. Historical alarm records refer to historical archived data that standardizes and stores triggered alarm information for subsequent tracing and analysis.

[0129] As an optional implementation, for each target screen, screen health data is extracted, and the device communication status of that screen is detected based on this data. The system identifies any anomalies in the connectivity and stability of the communication link and performs a working status check on the target screen, identifying any anomalies in hardware operation and task execution. When an anomaly is detected, a corresponding alarm level is matched according to the severity of the anomaly, triggering a tiered alarm of that level. The trigger time, anomaly type, and alarm level of this alarm are standardized, organized, and archived as historical alarm records. After processing all target screens, the status detection and alarm archiving of all screens are completed.

[0130] For example, in the scenario of managing public safety screens, operators, based on the management information of 126 screens within the district-level management authority, classify the devices hierarchically according to the administrative tree structure of city, district, street, and community, obtaining a list of screen device information including 86 PIS-LED65 and 40 PIS-LED55 screens, and simultaneously obtaining real-time online and offline status data of 118 screens and 8 screens. Then, the two types of data are linked according to multi-dimensional statistical rules to generate a status list, quantifying the health status data of 112 screens with normal health and 6 screens with abnormal health. Based on the health status data, screen status is detected, identifying abnormal situations such as 2 devices with communication interruptions and 4 devices with malfunctions, triggering tiered alarms of 2 emergency alarms and 4 general alarms, and archiving the 6 alarm messages as historical alarm records.

[0131] By combining administrative hierarchical classification, multi-dimensional health statistics, and graded alarm mechanisms, the problems of inaccurate device status perception, untimely anomaly detection, and insufficient alarm granularity in the management and control of public safety screens have been solved, thereby improving the efficiency of operation and maintenance management and the speed of anomaly response for public safety screens.

[0132] Based on any of the above embodiments, in Embodiment 8 of this application, before step S40, steps G11~G15 are further included: Step G11: Collect the operating power parameters of the target screen through the IoT control box.

[0133] In this embodiment, the IoT control box refers to a standardized end-side control terminal unit deployed on the target screen side, integrating multiple types of standardized hardware interfaces, possessing IoT communication capabilities, data acquisition functions, and video signal control capabilities. Its configured interfaces cover various mainstream video signal interfaces, including High Definition Multimedia Interface (HDMI), Video Graphics Array Interface (VGA), Digital Video Interface (DVI), and Serial Digital Interface (SDI), supporting video signal access from different types of public safety screens. It can also switch and control the video signal source of the target screen, and simultaneously complete functions such as screen operating power acquisition, control link adaptation, and bidirectional data transmission with the control platform. It is the core functional carrier for realizing local closed-loop autonomous control of the end-side screen. It is used to realize the status acquisition and remote control of the target screen. Operating power parameters refer to power-related operating data generated in real time during the operation of the target screen, used to characterize the screen's power supply status, operating power consumption, and load conditions.

[0134] As an optional implementation, an IoT control box deployed on the target screen synchronously connects to the target screen's power supply acquisition interface according to a preset acquisition cycle, reading power-related data frame by frame during the target screen's operation. The acquired power-related data is processed, interference noise is removed, and the standardized operating power parameters are synchronously uploaded to the management terminal via the IoT communication link. After completing this acquisition, the above acquisition process is repeated in the next acquisition cycle.

[0135] As an alternative implementation, after deploying the IoT control box, the adaptation and access of various video signal interfaces are first completed. Various video source signals are connected to the high-definition multimedia interface, video graphics array interface, digital video interface, serial digital interface, and other video signal interfaces configured on the IoT control box. This establishes the transmission path between the interface and the target screen, while simultaneously ensuring that the power supply circuits of the target screen and the IoT control box remain normally connected, guaranteeing the continuous online operation of the IoT communication link. When remote shutdown and control operations of the target screen are required, there is no need to disconnect the power supply circuit of the target screen. The IoT control box locally executes the path cutoff operation of the corresponding video signal interface, cutting off the video signal transmission path from the control platform to the target screen. After the target screen detects no valid input video signal, it automatically enters standby mode, exhibiting a no-display standby effect completely consistent with power-off shutdown. Throughout the entire process, the power supply to the target screen and the IoT control box remains normal, and the IoT communication link remains connected and online at all times. When remote control of the target screen is required, the IoT control box locally performs the path opening operation of the corresponding video signal interface, restoring the video signal transmission path from the control platform to the target screen. After the target screen detects a valid input video signal, it automatically exits the standby state and resumes normal content display, completing the remote control of the target screen. The entire process does not require any switching operation of the power supply circuit. This method addresses the core pain point of traditional power-operated remote switch control: when power is cut off, the screen and control box lose power, and the communication link is interrupted, making remote wake-up impossible. The communication link remains continuously online throughout the process, allowing for immediate response to remote control commands. Furthermore, it eliminates the need for additional special remote wake-up hardware on the screen, making it compatible with most conventional public safety screens with automatic standby functionality when there is no signal. Its adaptability is extremely high, and it avoids the impact and wear on the screen's power hardware caused by frequent power on / off cycles, effectively extending the screen's lifespan. It also supports adaptation to multiple video interfaces, covering the control needs of public safety screens of different models and configurations. This achieves remote screen soft-switch control without power interruption, completely resolving the industry pain point of traditional remote power-off switches being unable to be remotely woken up. It significantly improves the reliability and adaptability of remote control, ensuring that remote switching operations on the target screen can be completed at any time, while reducing hardware wear and tear, perfectly adapting to the routine remote control needs of public safety screens.

[0136] Step G12: Determine the power type of the target screen based on the operating power parameters and power parameter thresholds.

[0137] In this embodiment, the power parameter threshold refers to the boundary judgment standard preset by the system for classifying different power types.

[0138] As an optional implementation, the operating power parameters of the target screen are extracted, and all ranges of power parameter threshold divisions are obtained. For the current operating power parameter, it is matched and compared with all threshold ranges one by one to identify the threshold range to which the current parameter belongs. Based on the matched threshold range, the corresponding power type is determined. After this determination is completed, the determination result is synchronously stored for subsequent control operation adaptation.

[0139] As an alternative implementation, the operating power parameters of the target screen throughout the entire time period are extracted. Based on the temporal distribution characteristics of these operating power parameters, feature extraction is performed to generate a power temporal feature vector for the screen. Temporal feature templates for various power types corresponding to power parameter thresholds are obtained. The generated temporal feature vector is then clustered and matched with all feature templates to identify the feature template with the highest matching degree. Based on the matched feature template, the corresponding power type is determined. After this determination is completed, the determination result is synchronously stored for subsequent control and management operation adaptation.

[0140] Step G13: Match the corresponding management link according to the power type, and configure the exclusive adaptation configuration of the management link according to the link configuration parameter library.

[0141] In this embodiment, the link configuration parameter library refers to a standardized data storage unit that is pre-set by the system and centrally stores the configuration parameters and adaptation rules of all controlled links. Dedicated adaptation configuration refers to dedicated transmission and control adaptation parameters configured for a specific controlled link, adapting to the corresponding power type and link characteristics.

[0142] As an optional implementation, the matching rules between power type and control link are retrieved, and the corresponding dedicated control link is matched based on the power type. The basic configuration parameters corresponding to this control link are obtained from the link configuration parameter library. For the current control path, the transmission characteristics of the path and the power characteristics of the target screen are extracted, and personalized adjustments are made based on the basic configuration parameters to generate a dedicated adaptation configuration for this control path. The generated dedicated adaptation configuration is synchronously distributed to both ends of the control path to complete the configuration of the control path.

[0143] As an alternative implementation, screens are grouped based on power type similarity, with screens of the same power type grouped into the same cluster group. For each cluster group, the corresponding multi-link cluster management link is matched based on the cluster's power type, and the basic configuration parameters corresponding to that cluster link are obtained from the link configuration parameter library. For all management paths within the cluster, the transmission characteristics of all paths are extracted, and batch adjustments are performed based on the basic configuration parameters to generate a dedicated adaptation configuration for all management paths. The generated dedicated adaptation configuration is then synchronously distributed to both ends of all management paths to make the configuration effective for all management paths.

[0144] As an alternative implementation, an IoT control box deployed on the target screen side is connected, and the IoT control box locally collects the operating power parameters of the target screen. It locally acquires preset power parameter thresholds, determines the power type, and classifies the screen as either a normal power screen or an ultra-high power screen as a controllable object. It acquires preset differentiated control link matching rules, matches differentiated control links to controllable objects of different power types, configures power supply circuit control links for normal power screens, and configures signal source control links for ultra-high power screens, completing the dedicated adaptation configuration of the control path, and synchronously reports the configuration results to the control terminal. In the traditional centralized management and control model for public screens, relying on the cloud to uniformly identify screen power differences and configure management links cannot adapt to the dynamic changes in real-time power of a single screen. This easily leads to problems such as link matching errors and delayed management response. For example, if all screens use a fixed management link for operation and maintenance, some high-power screens are still matched with conventional power supply circuit management links. This makes it impossible to specifically manage the operating status of signal sources, which can easily lead to load anomalies and management failures. It is necessary to rely on manual on-site power verification and manual switching of management links, which is not only inefficient but also makes it difficult to achieve unified and refined management on the platform. This technical solution solves the problems of delayed adaptation and inaccurate link matching in the cloud-based unified management and control by using a closed-loop approach of local power acquisition, local type determination, and local matching of differentiated management links in the IoT control box. It also eliminates the inefficiency of manual on-site debugging and achieves automated management and control with end-side autonomous adaptation and unified platform filing. This significantly improves the accuracy, response speed, and overall operation and maintenance efficiency of power adaptation and link management for public safety screens.

[0145] Furthermore, for public safety target screens deployed with IoT control boxes, the following operations are performed: The side-end IoT control box locally collects the operating power parameters of the target screen, retrieves the preset power parameter threshold to complete the local power type determination, and divides the screens into two categories of control objects: normal power screens and ultra-high power screens. According to the differentiated control link matching rules, a power supply circuit control link is matched for normal power screens, and a signal source control link is matched for ultra-high power screens. The exclusive adaptation configuration of the corresponding control path is completed, and the final adaptation configuration result is then synchronously uploaded to the control terminal for filing and retention.

[0146] Step G14: Deploy the hierarchical communication scheme for the target screen according to the scenario requirements and communication deployment strategy of the target screen.

[0147] In this embodiment, scenario requirements refer to the communication real-time performance, reliability, and bandwidth requirements corresponding to the scenario in which the target screen is located. Communication deployment strategy refers to the communication deployment rules and adaptation strategies preset by the system for different scenarios and communication conditions. Hierarchical communication scheme refers to a standardized communication deployment scheme that divides communication into different priorities and levels to adapt to different needs.

[0148] As an optional implementation, corresponding end-to-end communication deployment rules are matched based on scenario requirements. For the target screen, a star-shaped hierarchical communication architecture is deployed from the control end to the screen end, different communication priorities are defined for control commands, status data, and media data, and transmission rules and bandwidth allocation for data of different priorities are configured. The hierarchical communication scheme is configured and implemented, realizing end-to-end hierarchical communication control of the target screen.

[0149] As an alternative implementation, screens are grouped based on the similarity of scenario requirements. For each group, a mesh-based hierarchical communication architecture is deployed, enabling interconnected communication between screens within the cluster. Based on the communication deployment strategy, a local communication layer within the cluster and an uplink communication layer from the cluster to the management terminal are defined, configuring communication priorities, bandwidth allocation, and transmission rules for different layers. This completes the configuration and implementation of the hierarchical communication scheme, achieving interconnected hierarchical communication management within the cluster.

[0150] Step G15: Based on the adapted control link and the hierarchical communication deployment scheme, a two-way data communication channel is constructed between the public screen management platform and the IoT control box to establish transmission support for the issuance of control commands and the return of terminal status.

[0151] In this embodiment, the adapted control link refers to a differentiated control transmission link for different power types that has already undergone dedicated adaptation configuration. The public screen management platform refers to a cloud-based management service platform used for centralized control of public screens. The bidirectional data communication channel refers to a bidirectional data transmission channel between the public screen management platform and the IoT control box.

[0152] As an optional implementation, a fully adapted management and control link and hierarchical communication deployment scheme are obtained. Based on the affiliation and characteristics of all IoT control boxes, cluster groups are established. For each cluster group, an uplink bidirectional channel from the common screen management platform to the cluster gateway is constructed, along with local mesh bidirectional channels between all control boxes within the cluster. Transmission priorities for different channel levels are configured based on the hierarchical communication scheme, and dedicated transmission adaptation parameters for all channels are configured based on the management and control link. Handshake verification and configuration activation for all channels are completed. This establishes coordinated transmission support for the issuance of control commands and the feedback of terminal status from all control boxes within the cluster.

[0153] For example, in the scenario of managing public safety screens, the operating power parameters of all screens are collected by IoT control boxes deployed on the side of 82 target screens. Among them, 76 screens are PIS-LED65 type screens and 6 are PIS-LED100 type screens. Based on the preset power parameter threshold, the power type is determined, and the 76 screens with normal power and 6 screens with ultra-high power are divided into two categories of managed objects. Power supply circuit management links are matched for normal power screens, and signal source management links are matched for ultra-high power screens. The dedicated adaptation configuration of the two types of management links is completed according to the link configuration parameter library. Then, based on the scenario requirements and communication deployment strategies of all screens, the hierarchical communication scheme is deployed. Finally, based on the adapted management links and hierarchical communication deployment scheme, a two-way data communication channel is built between the public screen management platform and all IoT control boxes, which establishes transmission support for subsequent control command issuance and terminal status feedback.

[0154] By using a linkage mechanism of power sensing, link adaptation, and hierarchical communication, the problems of inaccurate link adaptation, low communication transmission efficiency, and insufficient bidirectional transmission support in public safety screen management have been solved, thereby improving the transmission adaptability and communication reliability of public safety screen management.

[0155] This application provides a control device for an AI-based public safety screen. The control device for the AI-based public safety screen includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the control method for the AI-based public safety screen in the first embodiment described above.

[0156] The following is for reference. Figure 5The diagram illustrates a structural schematic of a control device suitable for implementing an AI-based public safety screen according to embodiments of this application. The control device for the AI-based public safety screen in these embodiments may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital signage controllers, video matrix controllers, and industrial-grade IoT gateways, as well as fixed terminals such as edge computing control terminals and desktop computers. Figure 5 The AI-based public safety screen control device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0157] like Figure 5 As shown, the control device for the AI-based public safety screen may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 1002 or a program loaded from storage device 1003 into random access memory (RAM) 1004. The random access memory 1004 also stores various programs and data required for the operation of the AI-based public safety screen control device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the AI-based public safety screen control device to communicate wirelessly or wiredly with other devices to exchange data. Although the figure shows an AI-based public safety screen control device with various systems, it should be understood that it is not required to implement or have all the systems shown. More or fewer systems can be implemented alternatively.

[0158] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0159] The AI-based public safety screen control device provided in this application, employing the AI-based public safety screen control method described in the above embodiments, can solve the technical problem of low efficiency in screen operation and maintenance management. Compared with the prior art, the beneficial effects of the AI-based public safety screen control device provided in this application are the same as those of the AI-based public safety screen control method provided in the above embodiments, and other technical features in this AI-based public safety screen control device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0160] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0161] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0162] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the AI-based public safety screen control method in the above embodiments.

[0163] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, radio frequency (RF), etc., or any suitable combination thereof.

[0164] The aforementioned computer-readable storage medium may be included in the control device of the AI-based public safety screen; or it may exist independently and not be assembled into the control device of the AI-based public safety screen.

[0165] The aforementioned computer-readable storage medium carries one or more programs. When these programs are executed by an AI-based public safety screen control device, the AI-based public safety screen control device: in response to an account login operation, determines screen control information within the scope of the account's control permissions; in response to a screen control request based on the screen control information, generates a screen control policy based on the priority of the screen control request; maps control instructions for the target screen according to the screen control policy and its corresponding target screen's state information; and issues the control instructions according to the sending sequence of the control instructions to control the target screen.

[0166] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0167] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation that may be implemented in systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0168] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0169] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described AI-based public safety screen control method, thereby solving the technical problem of low efficiency in screen operation and maintenance management. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the AI-based public safety screen control method provided in the above embodiments, and will not be repeated here.

[0170] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A control method for a public safety screen based on AI, characterized in that, The method includes: In response to an account login operation, screen control information within the scope of the account's control permissions is determined. In response to the screen control request in the screen control information, a screen control policy is generated based on the priority of the screen control request; Based on the screen control strategy and the status information of the corresponding target screen, the control instructions for the target screen are mapped to obtain the control instructions for the target screen. The control commands are sent according to the specified timing to control the target screen.

2. The control method for an AI-based public safety screen as described in claim 1, characterized in that, The step of determining screen control information within the scope of control permissions based on the account's control permissions in response to an account login operation includes: After completing the account login operation and generating the identity credential corresponding to the account, the corresponding hierarchical control permissions and geographical jurisdiction boundaries are matched in the permission management database based on the identity credential. Based on the hierarchical control permissions and the geographical jurisdiction boundaries, and combined with environmental weighting calculations, the scope of control permissions for the account is determined. Based on the scope of the account's management permissions, screen management information within the scope of the management permissions is filtered out from the full screen information and displayed.

3. The control method for an AI-based public safety screen as described in claim 2, characterized in that, The step of determining the scope of control permissions for the account based on the hierarchical control permissions and the geographical control boundaries, combined with environmental weighting calculations, includes: Based on the login location of the account and the factors influencing the login location, a login location weight is generated according to the weighting rules. Based on the environmental impact factors of the scene where each screen to be managed is located, the weights of the impact factors are generated according to the environmental impact additional rules. The environmental weight is calculated by combining the landing site weight with the impact factor weight and a preset weight ratio. The hierarchical control permissions and the geographical control boundaries are respectively weighted by the environmental weights to obtain the weighted hierarchical permissions and the weighted geographical boundaries. According to the permission scope determination rules, the conflict between the weighted hierarchical permissions and the weighted geographical boundary permission scope is adjusted to obtain the management permission scope of the account.

4. The control method for an AI-based public safety screen as described in claim 1, characterized in that, The step of generating a screen control policy in response to a screen control request in accordance with the screen control information and taking into account the priority of the screen control request includes: In response to the screen control request, the priority of the screen control request is calculated by weighting according to the control type of the screen control request, the corresponding screen state and the security level of the scene in which the screen is located, according to the priority weighting rules. Based on the priority of the screen control request, compare it with the priority of conflicting screen control requests to obtain the priority comparison result; After adjusting the screen control request based on the priority comparison result, the screen control strategy is generated according to the adjusted screen control request and its corresponding execution sequence.

5. The control method for an AI-based public safety screen as described in claim 1, characterized in that, The step of mapping the control command of the target screen according to the screen management strategy and its corresponding target screen state information includes: The screen control strategy is analyzed, and the control parameters are obtained by combining the operating parameters of the target screen. Based on the status information of the target screen corresponding to the screen control strategy, the power type and control link attributes of the target screen are determined; Based on the power type of the target screen and the attributes of the control link, the adaptability of the control parameters is verified, and the adaptability parameters are adjusted to obtain the appropriate parameters. The adaptation parameters are mapped into control commands that conform to the target screen terminal communication according to the execution encoding mapping rules.

6. The control method for an AI-based public safety screen as described in claim 1, characterized in that, The step of sending the control commands according to the timing of the control commands to manage the target screen includes: Based on the execution sequence of the screen control request and the corresponding link delay, the sending sequence of the control command corresponding to the screen control request is determined. Based on the transmission timing, the control commands are sent sequentially to the corresponding target screens via IoT communication services. The system receives terminal receipt information and instruction execution status transmitted from the target screen to control the target screen to complete the content of the control instruction.

7. The control method for an AI-based public safety screen as described in claim 1, characterized in that, Following the step of determining screen control information within the scope of account control permissions based on the account's control permissions in response to an account login operation, the AI-based public safety screen control method further includes: Based on the screen control information within the scope of the control authority, the devices are hierarchically classified according to the administrative tree structure to obtain a list of screen device information and real-time online and offline status data. The list-style screen device information and the real-time online and offline status data are linked together with the status list according to multi-dimensional statistical rules to quantify and generate screen health data. Based on the screen health data, the device communication and working status of the screen are detected, and a graded alarm is triggered and historical alarm records are archived when an abnormality occurs.

8. The control method for an AI-based public safety screen as described in claim 1, characterized in that, Before the step of issuing the control commands according to the timing of the control commands to manage the target screen, the AI-based public safety screen control method further includes: The operating power parameters of the target screen are collected through the IoT control box; The power type of the target screen is determined based on the operating power parameters and power parameter thresholds. Match the corresponding management link according to the power type, and configure the exclusive adaptation configuration of the management link according to the link configuration parameter library; Based on the scenario requirements and communication deployment strategy of the target screen, deploy a hierarchical communication scheme for the target screen; Based on the adapted control link and the hierarchical communication deployment scheme, a two-way data communication channel is constructed between the public screen management platform and the IoT control box, providing transmission support for the issuance of control commands and the feedback of terminal status.

9. A control device for a public safety screen based on AI, characterized in that, The control device for the AI-based public safety screen includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the control method for the AI-based public safety screen as described in any one of claims 1 to 8.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the AI-based public safety screen control method as described in any one of claims 1 to 8.

Images