A risk deployment method, device, equipment and medium of a honghome device

Abstract

This invention discloses a risk control method, apparatus, device, and medium for HarmonyOS devices. The method includes: acquiring a current risk event and determining event information of the current risk event, wherein the event information includes event content and event type; selecting a target control scheme from candidate control schemes to handle the current risk event based on the event information; wherein the target control scheme includes the target device type of the target control device required to handle the current risk event; determining the target HarmonyOS device based on the target device type and event content; networking the target HarmonyOS devices based on a distributed soft bus and sending control commands to each target HarmonyOS device, wherein the control commands are used to control the target HarmonyOS devices to complete device actions to respond to the current risk event. The technical solution provided by this invention can improve the timeliness of risk control response and improve the efficiency of risk event handling.

Description

Technical Field

[0001] This invention relates to the field of risk management, and in particular to a risk control method, apparatus, equipment and medium for HarmonyOS devices. Background Technology

[0002] In modern industrial production and public safety, risk events are often characterized by their suddenness, severity, and cascading effects. An effective risk management system is the core line of defense for protecting personnel safety, maintaining property integrity, and ensuring production continuity. The essence of risk management is to control potential risks within acceptable limits through systematic identification, assessment, monitoring, and intervention. In the context of digital transformation, risk management has shifted from passive response to proactive prevention, and from single-point management to systemic coordination. Its significance lies in minimizing the threat to personnel safety from emergencies and reducing equipment damage, production interruptions, and economic losses caused by risk events through real-time monitoring and rapid response.

[0003] However, current control of management terminals generally requires multiple levels of management personnel to manually activate the equipment, resulting in slow response times and untimely risk handling. Summary of the Invention

[0004] This invention provides a risk control method, apparatus, device, and medium for HarmonyOS devices. Through the technical solution of this invention, a control scheme can be quickly determined, control devices can be quickly networked through a distributed soft bus, and control devices can be controlled to perform device actions, thereby achieving timely response to risk events.

[0005] In a first aspect, embodiments of the present invention provide a risk control method for HarmonyOS devices, including: Obtain the current risk event and determine the event information of the current risk event, wherein the event information includes event content and event type; Based on the event information of the current risk event, a target deployment scheme for handling the current risk event is selected from the candidate deployment schemes; wherein, the target deployment scheme includes the target equipment type of the target deployment equipment required to handle the current risk event; Based on the target device type and event content, the target HarmonyOS device is determined; The target HarmonyOS devices are networked based on a distributed soft bus, and control commands are sent to each target HarmonyOS device. The control commands are used to control the target HarmonyOS devices to complete device actions in order to respond to the current risk event.

[0006] Secondly, embodiments of the present invention provide a risk control device for HarmonyOS devices, including: The acquisition module is used to acquire the current risk event and determine the event information of the current risk event, wherein the event information includes event content and event type; The scheme determination module is used to select a target deployment scheme for handling the current risk event from candidate deployment schemes based on the event information of the current risk event; wherein, the target deployment scheme includes the target equipment type of the target deployment equipment required to handle the current risk event; The device determination module is used to determine the target HarmonyOS device based on the target device type and event content; The control module is used to network the target HarmonyOS devices based on a distributed soft bus and send control commands to each target HarmonyOS device. The control commands are used to control the target HarmonyOS devices to perform device actions in order to respond to the current risk event.

[0007] Thirdly, embodiments of the present invention provide an electronic device, the electronic device comprising: At least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, which is then executed by the at least one processor to enable the at least one processor to execute the risk control method for HarmonyOS devices as described in any one of the embodiments of the present invention.

[0008] Fourthly, embodiments of the present invention provide a computer-readable storage medium storing computer instructions, which are used to cause a processor to execute the risk control method for the HarmonyOS device as described in any one of the embodiments of the present invention.

[0009] This invention provides a risk control method, apparatus, device, and medium for HarmonyOS devices. The method includes acquiring a current risk event and determining event information of the current risk event, wherein the event information includes event content and event type; selecting a target control scheme from candidate control schemes to handle the current risk event based on the event information of the current risk event; wherein the target control scheme includes target device types of target control devices required to handle the current risk event; determining target HarmonyOS devices based on the target device type and event content; networking the target HarmonyOS devices based on a distributed soft bus and sending control commands to each target HarmonyOS device, wherein the control commands are used to control the target HarmonyOS devices to complete device actions to respond to the current risk event. Specifically, by automatically determining the control scheme corresponding to the current risk event, quickly determining the target control devices based on the control scheme, and networking the target control devices through a distributed soft bus, rapid management and control of the target control devices can be achieved, improving the timeliness of risk response. Attached Figure Description

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

[0011] Figure 1 This is a flowchart of a risk control method for HarmonyOS devices provided in Embodiment 1 of the present invention; Figure 2 This is a flowchart of a risk control method for HarmonyOS devices provided in Embodiment 2 of the present invention; Figure 3 A schematic diagram illustrating risk control for HarmonyOS devices provided in an embodiment of the present invention; Figure 4 This is a schematic diagram generated for the target deployment scheme provided in the embodiments of the present invention; Figure 5 This is a schematic diagram of a risk control device for HarmonyOS devices provided in Embodiment 3 of the present invention; Figure 6 This is a schematic diagram of the structure of an electronic device provided in Embodiment 4 of the present invention. Detailed Implementation

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

[0013] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0014] It should be noted that the collection, storage, use, processing, transmission, provision, and disclosure of user personal information involved in the technical solution disclosed herein all comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0015] Example 1 Figure 1 This is a flowchart of a risk control method for HarmonyOS devices provided in Embodiment 1 of the present invention. Specifically, this embodiment of the present invention is applicable to controlling terminal devices to perform corresponding device actions when a risk event occurs, in order to deal with the current risk event. This method can be executed by a risk control device for HarmonyOS devices, which can be composed of software and / or hardware and is configured in a computer or server.

[0016] like Figure 1 As shown, it includes: Step 110: Obtain the current risk event and determine the event information of the current risk event, wherein the event information includes the event content and the event type.

[0017] Among them, the current risk event is a specific event that is happening or pending handling and has potential risk characteristics; the event information is a multi-dimensional data set describing the current risk event; the event content is the data in the event information that specifically describes the scenario, process, and objects involved in the risk event; and the event type is the category identifier in the event information that classifies the risk event according to the criteria such as cause, nature, and scope of impact, such as fire, flood, and explosion.

[0018] Step 120: Based on the event information of the current risk event, select a target deployment scheme from the candidate deployment schemes to handle the current risk event; wherein, the target deployment scheme includes the target equipment type of the target deployment equipment required to handle the current risk event.

[0019] The candidate deployment scheme is a pre-defined set of alternative solutions capable of handling different types of risk events. The target deployment scheme includes the target equipment types of the target deployment devices required to handle the current risk event. For example, for a fire event, the target deployment scheme may include terminal devices such as fire sprinklers, alarms, and cameras. The target deployment device is the hardware device explicitly required in the target deployment scheme to handle the current risk event, used to perform specific prevention or intervention operations. By executing corresponding control actions, the target deployment device can respond to the current risk event; for example, in the event of a fire, actions such as quickly sounding an alarm or opening sprinklers can be used to handle the current risk event. The target equipment type refers to the category of equipment in the target deployment scheme, categorized by function, form, technical parameters, and location.

[0020] It should be noted that since it is unclear whether the terminal device can be used and whether it meets the current risk event handling requirements, the deployment plan only includes the types of devices to be deployed and does not involve specific device terminals. The selection of device terminals needs to be done according to the subsequent methods of the present invention.

[0021] Specifically, the method for determining the candidate deployment scheme includes: The process involves acquiring event information, historical control devices, and corresponding control results for historical risk events, where the control results characterize the effectiveness of the device types of historical control devices in handling historical risk events; determining target historical control devices based on the control results of historical control devices; extracting key fields from the event information and determining the event type of the historical risk event based on the key fields; establishing a mapping relationship between the event type, key fields, and device types of the target historical control devices to generate candidate control schemes.

[0022] The deployment results refer to the effectiveness feedback data generated by historical deployment equipment in handling historical risk events. This data characterizes the effectiveness of different equipment types in handling historical risk events, such as efficiency, success rate, and resource consumption. For example, for air conditioning equipment, the deployment results can be determined by comparing its effectiveness in "on" and "off" states during a fire scenario: if turning on the air conditioner effectively assists in the directional removal of smoke and reduces visibility interference in the fire scene, thereby improving fire handling efficiency and success rate, then the deployment results for this type of air conditioning equipment are judged as "good"; conversely, if the off state is more conducive to controlling the spread of fire or preventing the equipment itself from becoming an ignition source, then the deployment results in the off state may be judged as "good," while the on state would be "poor."

[0023] The target historical monitoring devices are those selected from historical monitoring devices whose monitoring results are better than a preset threshold. Key fields are feature fields extracted from historical event information that have a significant impact on event classification, such as risk level, occurrence scenario, and affected area. By using the key fields of a risk event, the event type can be determined.

[0024] Step 130: Determine the target HarmonyOS device based on the target device type and event content.

[0025] The target HarmonyOS device is a smart device that is equipped with the HarmonyOS operating system and meets the handling requirements, determined according to the target device type and event content. It is used to carry out distributed collaborative handling tasks and complete specific device actions.

[0026] Step 140: Network the target HarmonyOS devices based on the distributed soft bus and send control commands to each target HarmonyOS device. The control commands are used to control the target HarmonyOS devices to complete device actions in order to deal with the current risk event.

[0027] Specifically, the distributed soft bus is a fundamental capability of distributed systems supporting low-latency, high-reliability communication among multiple devices. It enables self-discovery, self-networking, and data sharing among devices. However, existing technologies for managing risk events within a region have significant limitations: all terminal devices within the management scope must be pre-included in the network, and specific devices are selected for management only when a risk event occurs. However, due to the large number of terminal devices covered by the network, problems such as increased network latency and resource consumption are easily triggered, making it difficult to meet the requirements of real-time and efficient risk response. This invention addresses these shortcomings by abandoning the full pre-networking model and instead focusing on specific target devices corresponding to the current risk event, quickly establishing a temporary communication network using the distributed soft bus. This network, centered on the target device, focuses on the actual needs of risk management, significantly reducing the network scale and complexity, thereby ensuring low-latency network transmission and high operational efficiency, providing reliable communication support for accurate and rapid response to risk events.

[0028] Specifically, a network formation command is sent to each target HarmonyOS device to generate a temporary deployment network; based on the temporary deployment network, control commands are sent to each target HarmonyOS device.

[0029] Optionally, receive the handling information of each target HarmonyOS device in response to the current risk event; and determine the deployment result of the device type corresponding to the target HarmonyOS device based on the handling information.

[0030] Specifically, after receiving a control command, the target HarmonyOS device will trigger preset device actions, such as the camera recording video and the alarm activating its alarm function. After the actions are completed, the device will send feedback information to the server: for example, the camera will upload the recorded video stream to the server, and the alarm will send the alarm audio data back to the server. Based on the handling results and feedback data of this risk event, the server can assess and determine the deployment result for the device type to which the target HarmonyOS device belongs. For example, in a fire scenario, if the camera in the target HarmonyOS device has its lens severely obscured by dense smoke, resulting in blurry video and missing key fire information, thus failing to effectively assist in risk assessment and subsequent handling, the deployment result for its "camera" device type in fire risk handling will be rated as "poor." Conversely, if the camera can clearly capture the fire dynamics and transmit them in real time in a similar scenario, the deployment result may be rated as "good" or "excellent." Through this dynamic evaluation based on actual handling performance, the deployment result accurately reflects the adaptability of the device type in specific risk scenarios.

[0031] This invention provides a risk control method for HarmonyOS devices. The method includes acquiring a current risk event and determining event information, wherein the event information includes event content and event type; selecting a target control scheme from candidate control schemes based on the event information; wherein the target control scheme includes target device types of target control devices required to handle the current risk event; determining target HarmonyOS devices based on the target device type and event content; networking the target HarmonyOS devices using a distributed soft bus and sending control commands to each target HarmonyOS device, wherein the control commands are used to control the target HarmonyOS devices to perform device actions to respond to the current risk event. Specifically, by automatically determining the control scheme corresponding to the current risk event, quickly determining the target control devices based on the control scheme, and networking the target control devices using a distributed soft bus, rapid management and control of the target control devices can be achieved, improving the timeliness of risk response.

[0032] Example 2 Figure 2 This is a flowchart of a risk control method for HarmonyOS devices provided in Embodiment 2 of the present invention. This method further defines the target control scheme and the target HarmonyOS device in the above embodiments.

[0033] Step 210: Obtain the current risk event and determine the event information of the current risk event, wherein the event information includes the event content and the event type.

[0034] Step 220: Based on the event type of the current risk event, determine the target control plan from the candidate control plans.

[0035] Specifically, the database pre-stores candidate deployment schemes, and the core components of each candidate deployment scheme include the mapping relationship between event type, key fields, and the device type of the target historically deployed devices (i.e., the correspondence rule of "scenario-feature-device type"). Based on this, the target deployment scheme can be accurately matched and determined from the stored candidate deployment schemes according to the event type of the current risk event.

[0036] For example, when a current risk event is identified as a "fire" type, the system retrieves the candidate deployment plan corresponding to the "fire" type from the database and determines it as the target deployment plan to meet the handling needs of fire type risks.

[0037] It should be noted that simultaneous matching can also be performed using both event type and key fields, but this will not be elaborated on here.

[0038] Step 230: If the target deployment plan cannot be determined from the candidate deployment plans based on the type of the current risk event, then extract the key fields of each target based on the event content of the current risk event.

[0039] Step 240: Match the target key fields with the key fields in each candidate deployment scheme, and determine the target deployment scheme based on the matching results.

[0040] Specifically, given the diverse nature of current risk events, simply identifying the type may not directly lead to a target control plan. Therefore, we can extract key target fields from the event content (such as the location of occurrence, environmental characteristics, risk level, and affected objects) and compare them with the pre-stored key field mapping relationships of candidate control plans. Finally, the candidate plan with the best matching degree is selected as the target control plan.

[0041] Optionally, determining the target deployment plan based on the matching results includes: Multiple candidate deployment schemes are obtained based on the matching results, including a first deployment scheme and multiple second deployment schemes. The different device types between the first deployment scheme and each of the second deployment schemes are determined, where the different device types are those present in the second deployment schemes but not in the first deployment scheme. Deployment results associated with the different device types in historical risk events are obtained. Based on the deployment results, a target different device type is determined, and this target different device type is added to the first deployment scheme to obtain the target deployment scheme.

[0042] Among them, the first deployment scheme can be the candidate deployment scheme with the best matching result, and the second deployment scheme can be the candidate deployment scheme with a preset ranking before the matching result.

[0043] Specifically, while this solution quickly identifies relatively optimal solutions by determining the target deployment scheme through similarity matching, it may suffer from localized adaptation biases. Therefore, a second deployment scheme (with a pre-defined ranking before the matching results) can be introduced as a supplementary reference. The differences in equipment types between the second and first deployment schemes often represent potential optimization directions proven effective in different scenarios (such as the unique role of a certain type of equipment in a specific environment). By associating the deployment results of different equipment types in historical risk events (such as handling efficiency and success rate), target equipment types with excellent performance can be selected and added to the first deployment scheme. This approach retains the core adaptability of the original scheme while incorporating the scenario-specific advantages of other schemes, compensating for potential coverage blind spots in single matching, and ultimately ensuring the scenario adaptability and completeness of the target deployment scheme.

[0044] Step 250: Determine the candidate HarmonyOS devices of the target device type from the preset HarmonyOS device table.

[0045] Specifically, the preset HarmonyOS device table stores all registered or callable subsequent HarmonyOS devices, and also indicates the device type of each candidate HarmonyOS device. Therefore, the candidate HarmonyOS device of the target device type can be determined from the preset HarmonyOS device table.

[0046] Step 260: Determine the target HarmonyOS device based on the event address, event requirements, and current status of each candidate HarmonyOS device in the event content.

[0047] The system precisely locates the risk location using GPS or scene identifiers (such as building floors or area codes), prioritizing devices near the event location to reduce communication latency. The current status of candidate HarmonyOS devices is assessed based on availability, such as battery level ≥20%, absence of fault alarms, and performance compatibility (e.g., camera resolution meeting the event's image quality requirements). When high-definition recording is required, devices with 4K resolution and sufficient battery power are prioritized; for remote mountainous locations, devices with stable signal strength are prioritized. Through a multi-dimensional weighted evaluation of the event location, event requirements, and the real-time status of each candidate device, the system ultimately determines the target HarmonyOS device with the best overall compatibility.

[0048] Step 270: Network the target HarmonyOS devices based on the distributed soft bus and send control commands to each target HarmonyOS device. The control commands are used to control the target HarmonyOS devices to complete device actions in order to deal with the current risk event.

[0049] This invention provides a risk control method for HarmonyOS devices. It employs a distributed soft bus to quickly network only the target devices, forming a temporary communication network. This solves the problems of high latency and resource consumption associated with full-scale pre-networking in existing technologies, ensuring high-speed and efficient network operation. Candidate control schemes are generated based on historical risk event information, control results, and mappings between key fields and event types, providing disposal options. Dynamic evaluation of control results accurately reflects device type compatibility. If event type matching fails, key fields are extracted for matching, and the first control scheme is supplemented by considering the differences in device types between the second and third control schemes, ensuring completeness.

[0050] Figure 3This diagram illustrates the risk control of HarmonyOS devices according to an embodiment of the present invention. Specifically, during the plan generation and storage phase, the system pre-defines structured plans (candidate deployment schemes) for different emergency scenarios, clarifying device types, execution actions, and collaborative logic to lay the foundation for subsequent responses. When an emergency occurs, the user confirms the scenario through a graphical interface and clicks the one-click deployment trigger command. The system then enters the phase of parsing the plan and generating device command sets. The engine queries the online status of the devices and transforms the target deployment scheme into executable commands for specific HarmonyOS devices. Subsequently, the commands are issued through OpenHarmony distributed soft bus technology. The soft bus, acting as an "information superhighway," automatically discovers, connects, and distributes commands point-to-point in real time to each target HarmonyOS device, breaking through the latency bottleneck of traditional central server forwarding. After receiving the commands, the physical device layer (cameras, alarms, mobile terminals, etc.) executes them and simultaneously feeds back status data and real-time images. Finally, the system aggregates and displays the status of all network devices and the actual situation on site in the command center, forming a closed-loop management of "trigger-execution-monitoring," achieving second-level deployment and visualized command for emergency response.

[0051] Figure 4 This diagram illustrates the generation of the target deployment scheme provided in this embodiment of the invention. Specifically, the system matches risk control plans (deployment schemes) based on the type and information of risk events. If a perfect match exists, an initial draft plan (target deployment scheme) is directly generated. If no perfect match exists or further optimization is needed, the system will use historical data and key field matching results to select Top-N similar risk control plans (as the first and second risk control plans) through cosine similarity calculation, and optimize the first risk control plan using the second risk control plan. Subsequently, the system enters the equipment resource conflict detection and resolution stage, automatically identifying equipment instruction logic conflicts and resource competition, and automatically resolving conflicts according to priority rules. Finally, the optimized executable plan (target risk control scheme) is output, completing the digital configuration of emergency response. Simultaneously, the system stores the new plan and performs self-learning, continuously updating the historical database to achieve self-learning optimization of the algorithm and continuous improvement of the plan library.

[0052] Example 3 Figure 5 This is a schematic diagram of a risk control device for a HarmonyOS device provided in Embodiment 3 of the present invention. Figure 5 As shown, the device includes: The acquisition module 310 is used to acquire the current risk event and determine the event information of the current risk event, wherein the event information includes event content and event type; The scheme determination module 320 is used to select a target deployment scheme for handling the current risk event from candidate deployment schemes based on the event information of the current risk event; wherein, the target deployment scheme includes the target equipment type of the target deployment equipment required to handle the current risk event; The device determination module 330 is used to determine the target HarmonyOS device based on the target device type and event content; The control module 340 is used to network the target HarmonyOS devices based on a distributed soft bus and send control commands to each target HarmonyOS device. The control commands are used to control the target HarmonyOS devices to perform device actions in order to respond to the current risk event.

[0053] This invention provides a risk control device for HarmonyOS devices. The device involves: acquiring a current risk event; determining event information, including event content and event type; selecting a target control scheme from candidate control schemes based on the event information; wherein the target control scheme includes the target device type of the target control device required to handle the current risk event; determining the target HarmonyOS device based on the target device type and event content; networking the target HarmonyOS devices using a distributed soft bus; and sending control commands to each target HarmonyOS device, wherein the control commands are used to control the target HarmonyOS devices to perform actions in response to the current risk event. Specifically, by automatically determining the control scheme corresponding to the current risk event, quickly identifying the target control device based on the control scheme, and networking the target control device using a distributed soft bus, rapid management and control of the target control device can be achieved, improving the timeliness of risk response.

[0054] The device further includes: a scheme generation module, comprising: The acquisition unit is used to acquire event information of historical risk events, historical control devices and corresponding control results, wherein the control results are used to characterize the effect of the device type of historical control devices on the handling of historical risk events; The determination unit is used to determine the target historically deployed device based on the deployment results of historically deployed devices. A type determination unit is used to extract key fields from event information and determine the event type of historical risk events based on the key fields. The establishment unit is used to establish the mapping relationship between the event type, key fields and the device type of the target historical deployment device, and generate candidate deployment schemes.

[0055] The scheme determination module 320 includes: The first determining unit is used to determine the target deployment plan from among the candidate deployment plans based on the event type of the current risk event. The extraction unit is used to extract key fields of each target based on the event content of the current risk event if the target deployment plan cannot be determined from each candidate deployment plan according to the type of the current risk event. The matching unit is used to match the target key fields with the key fields in each candidate deployment scheme, and determine the target deployment scheme based on the matching results.

[0056] Matching units, including: The acquisition subunit is used to acquire multiple candidate deployment schemes based on the matching results, wherein the multiple candidate deployment schemes include a first deployment scheme and multiple second deployment schemes; The difference determination subunit is used to determine the difference device types between the first deployment scheme and each of the second deployment schemes. The difference device types are device types that exist in the second deployment schemes but do not exist in the first deployment schemes. The result acquisition unit is used to acquire the deployment results associated with different equipment types in historical risk events; The update unit is used to determine the target differential device type based on the deployment results, add the target differential device type to the first deployment scheme, and obtain the target deployment scheme. Optionally, the device determination module 330 includes: The candidate device determination unit is used to determine candidate HarmonyOS devices of the target device type from a preset HarmonyOS device table; The target device determination unit is used to determine the target HarmonyOS device based on the event address, event requirements, and the current status of each candidate HarmonyOS device in the event content.

[0057] Optionally, the control module 340 includes: The networking unit is used to send networking commands to each target HarmonyOS device and generate a temporary deployment network. The control unit is used to send control commands to each target HarmonyOS device based on the temporary deployment network.

[0058] The risk control device for HarmonyOS devices provided in this embodiment of the invention can execute the risk control method for HarmonyOS devices provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the method.

[0059] Example 4 Figure 6A schematic diagram of an electronic device 10, which can be used to implement embodiments of the present invention, is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0060] like Figure 6 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 can also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0061] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0062] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as the risk control methods of HarmonyOS devices.

[0063] In some embodiments, the risk control method for HarmonyOS devices can be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program can be loaded and / or installed on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the risk control method for HarmonyOS devices described above can be performed. Alternatively, in other embodiments, processor 11 can be configured to execute the risk control method for HarmonyOS devices by any other suitable means (e.g., by means of firmware).

[0064] Various implementations of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various implementations may include: implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0065] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0066] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on 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.

[0067] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0068] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0069] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0070] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0071] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A risk control method for HarmonyOS devices, characterized in that, include: Obtain the current risk event and determine the event information of the current risk event, wherein the event information includes event content and event type; Based on the event information of the current risk event, a target deployment scheme for handling the current risk event is selected from the candidate deployment schemes; wherein, the target deployment scheme includes the target equipment type of the target deployment equipment required to handle the current risk event; Based on the target device type and event content, the target HarmonyOS device is determined; The target HarmonyOS devices are networked based on a distributed soft bus, and control commands are sent to each target HarmonyOS device. The control commands are used to control the target HarmonyOS devices to complete device actions in order to respond to the current risk event.

2. The method according to claim 1, characterized in that, The method for determining the candidate deployment scheme includes: Acquire event information, historical control devices, and corresponding control results of historical risk events, wherein the control results are used to characterize the effect of the device type of historical control devices on the handling of historical risk events; Based on the deployment results of historically deployed devices, identify the target historically deployed devices; Extract key fields from event information, and determine the event type of historical risk events based on the key fields; Establish a mapping relationship between the event type, key fields and the device type of the target historically deployed device, and generate candidate deployment schemes.

3. The method according to claim 1, characterized in that, The step of determining the target deployment plan for handling the current risk event based on the event information of the current risk event includes: Based on the event type of the current risk event, determine the target control plan from the candidate control plans; If the target control plan cannot be determined from the candidate control plans based on the type of the current risk event, then extract the key fields of each target based on the event content of the current risk event. The target key field is matched with the key fields in each candidate deployment scheme, and the target deployment scheme is determined based on the matching results.

4. The method according to claim 3, characterized in that, The step of determining the target deployment plan based on the matching results includes: Multiple candidate deployment schemes are obtained based on the matching results, wherein the multiple candidate deployment schemes include a first deployment scheme and multiple second deployment schemes; Determine the different device types between the first deployment scheme and each of the second deployment schemes, wherein the different device types are device types that exist in the second deployment schemes but do not exist in the first deployment schemes; Obtain the deployment results associated with different equipment types in historical risk events; Based on the deployment results, the target differential device type is determined, and the target differential device type is added to the first deployment scheme to obtain the target deployment scheme.

5. The method according to claim 1, characterized in that, The determination of the target HarmonyOS device based on the target deployment scheme, according to the target device type and event content, includes: From the preset HarmonyOS device list, determine the candidate HarmonyOS devices for the target device type; The target HarmonyOS device is determined based on the event address, event requirements, and the current status of each candidate HarmonyOS device.

6. The method according to claim 1, characterized in that, The process of networking the target HarmonyOS devices based on a distributed soft bus and sending control commands to each target HarmonyOS device includes: Send networking commands to each target HarmonyOS device to generate a temporary deployment network; Based on the temporary deployment network, control commands are sent to each target HarmonyOS device.

7. The method according to claim 1, characterized in that, Also includes: Receive information from each target HarmonyOS device regarding its handling of current risk events; Based on the processing information, the deployment result of the device type corresponding to the target HarmonyOS device is determined.

8. A risk control device for HarmonyOS devices, characterized in that, include: The acquisition module is used to acquire the current risk event and determine the event information of the current risk event, wherein the event information includes event content and event type; The scheme determination module is used to select a target deployment scheme for handling the current risk event from candidate deployment schemes based on the event information of the current risk event; wherein, the target deployment scheme includes the target equipment type of the target deployment equipment required to handle the current risk event; The device determination module is used to determine the target HarmonyOS device based on the target device type and event content; The control module is used to network the target HarmonyOS devices based on a distributed soft bus and send control commands to each target HarmonyOS device. The control commands are used to control the target HarmonyOS devices to perform device actions in order to respond to the current risk event.

9. An electronic device, characterized in that, The electronic device includes: At least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the risk control method for the HarmonyOS device according to any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that are used to cause the processor to execute the risk control method of the HarmonyOS device according to any one of claims 1-7.

Images