Device management method and device, device management platform

By acquiring device attribute information and assembling and registering state machines, the complexity of management caused by differences in different device manufacturers, types, and versions is resolved, thereby improving the compatibility and security of the device management platform.

CN123035102APending Publication Date: 2026-11-03HILLSTONE NETWORKS CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202611400373.7
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2026-09-10
Publication Date
2026-11-03

AI Technical Summary

Technical Problem

Network devices from different manufacturers, of different types and versions support different communication protocols, registration methods and processes during the registration process, which makes device management cumbersome and difficult to achieve unified management with existing technologies.

Method used

By acquiring device attribute information, a state machine is used to assemble the registration process, ensuring compatibility with registration of different devices, including differences in device manufacturers, types, and versions. A preset whitelist is used to improve security, and device operation information is monitored.

Benefits of technology

It enables unified management of different devices, reduces the burden on administrators, improves the compatibility and security of the device management platform, and reduces resource consumption.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN123035102A_ABST
    Figure CN123035102A_ABST
Patent Text Reader

Abstract

The application relates to the technical field of device management, and discloses a device management method and device, and a device management platform. The method comprises the following steps: in the case of receiving a first registration request, acquiring attribute information of a device corresponding to the first registration request; assembling a registration process according to the attribute information; the registration process comprises a plurality of states of device registration access and a flow transfer event of each state; the flow transfer event represents a condition for triggering state flow transfer; and a state machine configured with the registration process is used to register the device. In this way, the matched registration process is set according to the different attribute information of the device, so that the device management platform can be compatible with the registration and access of all devices, an administrator only needs to operate the newly-added device and does not need to pay attention to the differences between different devices, and the device management burden of the administrator can be reduced.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of equipment management technology, and in particular to an equipment management method and apparatus, and an equipment management platform. Background Technology

[0002] In modern network environments, various network devices, such as firewalls and security components, need to be registered with the platform in order to monitor device status, resource usage, and collect relevant logs.

[0003] However, due to differences in device manufacturers, device types, and device versions, the communication protocols, registration methods, and registration processes supported by different devices also vary. For example, some manufacturers' devices use WebSocket (a new application-layer network protocol) for communication, while others use HTTP (Hypertext Transfer Protocol). Furthermore, some types of devices initiate registration themselves, while others are initiated by the platform. In related technologies, different devices typically use different apps for device registration and management, but this method is very cumbersome. Therefore, how to achieve compatibility between the registration of different devices and provide unified management for various devices is an urgent problem to be solved.

[0004] It should be noted that the information disclosed in the background section above is only used to enhance the understanding of the background of this application, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0005] To provide a basic understanding of some aspects of the disclosed embodiments, a brief summary is given below. This summary is not intended as a general commentary, nor is it intended to identify key / important components or describe the scope of protection of these embodiments, but rather as a prelude to the detailed description that follows.

[0006] This application provides a device management method and apparatus, and a device management platform, to be compatible with the registration of different devices.

[0007] This application provides a device management method applied to a device management platform. The method includes: upon receiving a first registration request, obtaining attribute information of the device corresponding to the first registration request; assembling a registration process based on the attribute information; the registration process includes: multiple states for device registration and access and transition events for each state; transition events characterize the conditions that trigger state transitions; and registering the device using a state machine configured in the registration process.

[0008] In the above embodiments, considering the differences in attribute information among different devices, a matching registration process is set for each device's different attribute information. This ensures that the device management platform can be compatible with the registration and access of all devices. Administrators only need to operate the addition of new devices without having to worry about the differences between different devices, thus reducing the administrator's device management burden. Furthermore, the implementation method of this application does not require adding additional data transceiver components on the device side, and is non-intrusive to the device.

[0009] Furthermore, the attribute information includes: device manufacturer and device type; assembling the registration process based on the attribute information includes: determining the status of the device based on the device manufacturer; determining the flow event of the device based on the device type; and assembling based on the status and the flow event to obtain the registration process.

[0010] In the above embodiments, considering that the overall registration process of devices from the same manufacturer is generally similar, while the overall registration processes of different device manufacturers may differ slightly, the device manufacturer's information can accurately determine the device registration and access status. Considering that different device types have different capabilities, the device type can be used to determine the flow events that can trigger normal registration for that device, thus making the registration process, composed of status and flow events, applicable to that device for registration.

[0011] Furthermore, the attribute information also includes: device version; the method further includes: determining the information acquisition format of the device based on the device version; the information acquisition format is used to indicate the types of information that need to be acquired in the device information; assembling the registration process and the information acquisition format to obtain a new registration process.

[0012] In the above implementation, considering the significant differences in device information across different device versions, matching the information acquisition format with the device version standardizes the types of information required by different devices, thus facilitating information management for each device.

[0013] Furthermore, the device management method also includes: obtaining the protocol and port used in the registration process; and adding the protocol and port to a preset access whitelist.

[0014] In the above implementation, by pre-setting an access whitelist, only protocols and ports required in the device registration process are allowed to interact with the device management platform. This prevents unrelated devices from accessing the device management platform, reduces the registration pressure on the device management platform, and improves the security of the device management platform.

[0015] Furthermore, registering the device using the state machine configured in the registration process includes: storing the state machine in a preset state machine cache until a first preset condition is met, triggering the state machine to enter the first state in the registration process, and performing state transitions in the registration process according to the transition events; the first preset condition is receiving a second registration request from the device management platform, or receiving a third registration request from the device.

[0016] In the above implementation, the state machine is stored in a preset state machine cache, waiting for the device management platform to initiate a second registration request or for the device to initiate a third registration request, which can be compatible with devices with different initiation methods.

[0017] Furthermore, the state transition in the registration process is performed according to the transition event, including: if the transition event of the current state of the state machine is triggered externally, the state machine is stored in a preset state machine cache until the transition event of the current state occurs, at which point the state machine is activated to continue the state transition.

[0018] In the above implementation, considering that some transition events are triggered externally, the state machine cannot execute subsequent steps while waiting for the external trigger. At this time, the state machine is stored in a preset state machine cache, so that the device management platform does not need to keep the state machine running, which can reduce the resource consumption of the device management platform.

[0019] Furthermore, the device management method also includes: monitoring the device's operation information after the device registration is completed.

[0020] In the above implementation, monitoring the device operation information of the devices connected to the device management platform facilitates centralized management of each device.

[0021] Furthermore, the device management method also includes: in the event of a change in the configuration information of the device management platform, notifying the devices registered on the device management platform of the changed configuration information.

[0022] In the above implementation, by notifying the connected devices of their changed configuration information through the device management platform, it is possible to ensure that the devices can interact normally with the device management platform in the future.

[0023] This application provides a device management apparatus applied to a device management platform. The apparatus includes: an acquisition module, configured to acquire attribute information of a device corresponding to a first registration request upon receiving a first registration request; an assembly module, configured to assemble a registration process based on the attribute information; the registration process includes: multiple states for device registration and access and transition events for each state; the transition events characterize the conditions that trigger state transitions; and a registration module, configured to register the device using a state machine that configures the registration process.

[0024] This application provides an electronic device, including a processor and a memory. The memory stores computer-executable instructions that can be executed by the processor, and the processor executes the computer-executable instructions to implement the above-described device management method.

[0025] The above general description and the description below are exemplary and illustrative only and are not intended to limit this application. Attached Figure Description

[0026] One or more embodiments are illustrated by way of example with reference to the accompanying drawings. These illustrations and drawings do not constitute a limitation on the embodiments. Elements having the same reference numerals in the drawings are shown as similar elements. The drawings are not to be scaled. And wherein: Figure 1 This is a schematic diagram of the system architecture of a device management platform provided in an embodiment of this application; Figure 2 This is a flowchart illustrating a device management method provided in an embodiment of this application; Figure 3 This is a schematic diagram of a manufacturer selector provided in an embodiment of this application; Figure 4 This is a schematic diagram of a device type selector provided in an embodiment of this application; Figure 5 This is a schematic diagram of a device version selector provided in an embodiment of this application; Figure 6 This is a schematic diagram of a state machine cache provided in an embodiment of this application; Figure 7 This is a schematic diagram of a state machine provided in an embodiment of this application; Figure 8 This is a schematic diagram of a state transition provided in an embodiment of this application; Figure 9 This is a flowchart illustrating another device management method provided in an embodiment of this application; Figure 10 This is a schematic diagram of a device management apparatus provided in an embodiment of this application; Figure 11This is a schematic diagram of a device management platform provided in an embodiment of this application.

[0027] Figure label: 1: Acquisition module; 2: Assembly module; 3: Registration module; 4: Processor; 5: Communication interface; 6: Bus; 7: Memory. Detailed Implementation

[0028] To provide a more detailed understanding of the features and technical content of the embodiments of this application, the implementation of the embodiments of this application will be described in detail below with reference to the accompanying drawings. The accompanying drawings are for illustrative purposes only and are not intended to limit the embodiments of this application. In the following technical description, for ease of explanation, several details are used to provide a full understanding of the disclosed embodiments. However, one or more embodiments may still be implemented without these details. In other cases, well-known structures and devices may be simplified in their depiction to simplify the drawings.

[0029] The terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application 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 for the embodiments of this application described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion.

[0030] Unless otherwise stated, the term "multiple" means two or more.

[0031] The term "correspondence" can refer to an association or binding relationship. The correspondence between A and B means that there is an association or binding relationship between A and B.

[0032] See Figure 1 As shown, Figure 1This is a schematic diagram of the system architecture of the device management platform provided in this application embodiment. The device management platform includes an application layer and an architecture layer. An APP for user use is set up in the application layer. When the APP receives a first registration request, it calls the device registration management service API (Application Programming Interface) through the device registration management service SDK (Software Development Kit) to invoke the device registration access module. The device registration access module includes a device registration access implementer and a state machine. The device registration access implementer is used to assemble the registration process based on the device's attribute information, and configures the state machine of the registration process for device registration. The device attribute information may include: device manufacturer, device type, and device version. A manufacturer selector is set for the device manufacturer attribute to determine the device's status in the registration process. A device type selector is set for the device type attribute to determine the flow events of the device in the registration process. A device version selector is set for the device version attribute to determine the information acquisition format of the data that the device needs to obtain in the registration process.

[0033] In some embodiments, the registration process for devices from different manufacturers may differ significantly in terms of the registration initiator and communication protocols. For devices from the same manufacturer but different device types, the registration phase may differ in terms of verification methods and rules, supported interfaces, and heartbeat sending methods. For devices from the same manufacturer and of the same device type but different device versions, there may be inconsistencies in resource monitoring content, uploaded log data content, and data format.

[0034] For example, during device registration, different manufacturers may have various types of devices, and these devices may support different communication protocols, registration methods, and registration processes. For instance, manufacturer A might use HTTP communication, with the device management platform initiating registration proactively. Manufacturer B might use HTTP communication, with the device management platform initiating registration proactively, and WebSocket communication, with manufacturer B's devices initiating registration proactively. Other manufacturers might initiate registration using other protocols.

[0035] The differences between these devices place a significant burden on network administrators in terms of device management. This application's device management platform allows enterprises to uniformly register and connect devices to the platform for subsequent resource monitoring, log management, and other functions. Administrators only need to add devices without worrying about the differences between them. The device management platform will parse and execute different registration processes based on different manufacturers, device types, and versions, improving the platform's compatibility and scalability to meet diverse device access scenarios.

[0036] Example 1 See Figure 2 As shown, Figure 2This is a flowchart illustrating the device management method provided in this application embodiment, applied to a device management platform. The device management method includes: Step S101: Upon receiving the first registration request, obtain the attribute information of the device corresponding to the first registration request.

[0037] The first registration request can be initiated by the user on the device management platform. For example, the user fills in the device identifier of the device to be registered in the device management platform's app. At this point, the device management platform knows that the device corresponding to that device identifier needs to be registered.

[0038] Step S102: Assemble the registration process based on the attribute information.

[0039] The registration process includes multiple states of device registration and the transition events of each state.

[0040] Among them, the transition event represents the condition that triggers the state transition.

[0041] For example, a transition event can include a trigger event and an execution action. The trigger event indicates between two states the transition occurs between; that is, it describes the original state and the target state. The original state is the state that initiates the transition, and the target state is the state after the transition from the original state. The execution action indicates the operation required for the transition between the two states. The execution action can include whether to perform a synchronous or asynchronous operation, which protocol to use, the specific operation content, and when to send the trigger event. An example of an execution action is: the device management platform initiating an HTTP request to the device to obtain basic device information. Another example is: detecting that the device is sending device capabilities via a WebSocket channel. Typically, after the execution action is completed, a trigger event is sent, thus completing the transition between the two states. By setting transition events, the device can automatically transition to the corresponding state according to the transition event to complete the registration.

[0042] In some implementations, the attribute information includes: equipment manufacturer and equipment type. Step S102 may include: determining the equipment status based on the equipment manufacturer; determining the equipment transfer event based on the equipment type; assembling based on the status and transfer event to obtain the registration process.

[0043] In one optional embodiment of the above, determining the device status based on the device manufacturer can be achieved by searching for the corresponding status of the device manufacturer in a preset status database. The status database stores the correspondence between device manufacturers and statuses.

[0044] In another optional approach of the above embodiments, determining the state of the device based on the device manufacturer can be achieved by inputting the device manufacturer into a preset state model to obtain the state corresponding to the device manufacturer.

[0045] Optionally, the preset state model can be obtained by inputting sample manufacturers with state labels into a preset first training model for training to obtain the state model.

[0046] The first training model, such as a neural network model, is not limited here.

[0047] For example, a device management platform might pre-define a set of states that includes the required states for different devices. A single device might execute some or all of these states. By establishing a correspondence between device manufacturers and the states required during the registration process and storing this correspondence in a state database, and using a manufacturer selector to match manufacturers, the platform can obtain the states required for each manufacturer during the registration process. Combined with... Figure 3 As shown, Figure 3 The rounded rectangles with dashed lines represent states that need to be skipped, and the dashed arrows represent states that need to be triggered externally. Assume there are two device manufacturers, for example, manufacturer A and manufacturer B. The manufacturer selector matches the following states for device registration access for manufacturer A: GET_BASIC_INFO, REGISTRY, RUNNING_STATE, and ABNORMAL_REGISTER_STATE. The manufacturer selector matches the following states for device registration access for manufacturer B: HELLO, GET_CAPABILITIES, GET_SCHEMA, GET_BASIC_INFO, REGISTRY, RUNNING_STATE, and ABNORMAL_REGISTER_STATE.

[0048] In one optional embodiment of the above, determining the device's workflow event based on the device type can be achieved by searching for the workflow event corresponding to the device type in a preset first event database. The first event database stores the correspondence between device type, each state in the state set, and workflow events.

[0049] Optionally, if it is necessary to receive a third registration request from the device, or if the device needs to perform a state that requires acquiring device capabilities according to the manufacturer's determination, the device's flow event can be determined based on the device type. This can be done by searching for the flow event corresponding to the device type and device capabilities in a preset second event database. The second event database stores the correspondence between device capabilities, device types, and each state in the state set and the flow event.

[0050] Device capabilities refer to the actions and protocols that a device supports. For example, device A has the capability to support the HTTP protocol. Device B has the capability to support the WebSocket protocol.

[0051] In another optional embodiment described above, determining the flow event of a device based on the device type can be achieved by inputting the device type into a preset event model to obtain the flow event corresponding to the device type.

[0052] Optionally, the preset event model can be obtained by inputting the sample device type with the flow event label into the preset second training model for training to obtain the event model.

[0053] The second training model, such as a neural network model, is not limited here.

[0054] In another optional embodiment described above, determining the device flow event based on the device type can be done by: determining the device flow event based on the device type and the alternative status; wherein the alternative status is a status determined by the device manufacturer.

[0055] Determining the flow events for a device based on its device type and alternative status can be achieved by searching a pre-defined first event database for flow events that correspond to both the device type and the alternative status. This ensures that only the flow events corresponding to the required device status are matched.

[0056] For example, in addition to manufacturer differences, different types of devices also differ in the actual actions and communication protocols executed at each registration stage (registration status). A device type selector converts the actions and communication protocols of different device types into preset flow events. Combined with... Figure 4 As shown, assume there are two device types, device type a and device type b. Device type a is matched to show its REGISTRY state transition event as registration via an HTTP request. Device type b is matched to show its REGISTRY state transition event as registration via a WebSocket request.

[0057] In this way, by matching device types to determine the flow events, when a new device type appears, the flow events adapted to the new device type can be determined simply by modifying the event database, thus improving the compatibility and scalability of the device management platform.

[0058] In other implementations, the attribute information includes: device manufacturer, device type, and device version. Step S102 may include: determining the device status based on the device manufacturer; determining the device transfer event based on the device type; determining the device information acquisition format based on the device version; and assembling the data based on the status, transfer event, and information acquisition format to obtain the registration process.

[0059] In the above embodiments, determining the information acquisition format of the device based on the device version can be achieved by searching for the information acquisition format corresponding to the device version in a preset format database. The format database stores the correspondence between device versions and information acquisition formats.

[0060] The information acquisition format can be customized for each information type. For example, if the information type is basic information, the acquisition format would be: Device ID (identity number), Device Version, and Device Type. If the information type is registration information, the acquisition format would be the address and port used during registration. If the information type is monitoring information, the acquisition format would be CPU utilization.

[0061] For example, in addition to differences in device type, different devices also differ in data information structure and data type. The device version selector converts the data from different device versions into unified data for unified persistence. Combined with... Figure 5 As shown, assume there are two device versions, device version 1 and device version 2. Device version 1 will have the basic information from basic information version 1. Device version 2 will have the basic information from basic information version 2. The basic information in basic information version 1 may include: device ID, device version, and device type. The basic information in basic information version 2 may include: device version and device type. Only information of the same type as the basic information in the information retrieval format is retained and stored in the persistence layer. That is, for the basic information in basic information version 2, only the device version and device type are retained and stored in the persistence layer. For the basic information in basic information version 1, only the device version and device type are retained and stored in the persistence layer. The persistence layer is the memory space used for storage.

[0062] In this way, by matching device versions to unify the types of data that need to be collected, when new devices bring new types of data, the new types of data can be unified simply by modifying the format database, thus improving the compatibility and scalability of the device management platform.

[0063] In some embodiments, if the device flow events are determined directly by the device type, and the registration process is obtained by assembling the status and flow events, it can be as follows: For each flow event: if the status corresponding to the flow event is not the status determined by the device manufacturer, then the execution action corresponding to the flow event is modified to empty. After performing the above steps for each flow event, the set of each flow event and the status corresponding to each flow event is used as the registration process.

[0064] In other embodiments, if the device flow events are determined by device type and alternative states, and the registration process is obtained by assembling based on the states and flow events, it may be as follows: Obtain the set sample states and the sample flow events corresponding to each sample state. For each sample state: if the alternative state matches the sample state, replace the sample flow event corresponding to that sample state with the flow event corresponding to the alternative state. After replacing all the flow events of the alternative states, the set consisting of the sample state and the sample flow events corresponding to each sample state is used as the registration process.

[0065] Each state in the state set can be treated as a sample state, and a corresponding sample transition event can be pre-set for each sample state; the execution action in each sample transition event is empty.

[0066] In some embodiments, the registration process also includes an information acquisition format. For flow events that require obtaining device information, the execution action is modified to acquire information according to the information acquisition format. For example, for a flow event that requires obtaining basic device information, the process is assembled to obtain the device version and device type from the basic device information.

[0067] In some embodiments, after obtaining the registration process, the device management platform assigns a unique device identifier to the device on the device management platform.

[0068] In some embodiments, after obtaining the registration process, the protocols and ports used in the registration process are obtained; these protocols and ports are then added to a preset access whitelist. This ensures that only the protocols and ports required by the device during the registration process are allowed to be accessed, thereby improving the security of the device management platform.

[0069] In some embodiments, upon receiving a first registration request, the device management platform creates a state machine for the device for registration. To facilitate differentiation between different state machines, a unique device identifier can be assigned to each state machine. After determining the device's registration process, the corresponding state machine registers the device according to that process.

[0070] Step S103: Register the device using the state machine of the configuration registration process.

[0071] In some embodiments, step S103 may involve storing the state machine in a preset state machine cache until a first preset condition is met, triggering the state machine to enter the first state in the registration process, and performing state transitions in the registration process according to the transition events.

[0072] The first preset condition is receiving a second registration request from the device management platform, or receiving a third registration request from the device. The second registration request is initiated by the device management platform during the registration phase. The third registration request is initiated by the device during the registration phase.

[0073] For example, in combination Figure 6 As shown, the state machine and its corresponding unique device identifier are stored in a preset state machine cache. The cache content can include each state and the transition events used for each state transition. Using the unique device identifier to mark the state machine ensures a one-to-one correspondence between the device and the state machine, preventing the registration of the device using an incorrect state machine.

[0074] In the above embodiments, the state transition in the registration process according to the transition event may include: if the transition event of the current state of the state machine is triggered by an external event, storing the state machine in a preset state machine cache until the transition event of the current state occurs, then activating the state machine to continue the state transition.

[0075] For example, in combination Figure 7 and Figure 8 As shown, in a state machine, if the action for a certain state does not exist, it directly transitions to the next state. During the registration process, if an exception occurs in the state machine, its state is set to ABNORMAL_REGISTER_STATE, and a state machine cleanup operation is performed, removing the state machine from the state machine cache. Different states transition through transition events. The state before the transition is the original state, and the state after the transition is the target state. Transition events can be divided into two main categories: actions for the original state, or asynchronous callback activation points. Actions for the original state include, for example, obtaining basic device information. Asynchronous callback activation points include, for example, messages returned by a Kafka (a distributed messaging system) message listener, HTTP requests initiated by a device, and target data sent via a WebSocket channel. Different devices can use different asynchronous callback activation points.

[0076] In some embodiments, the device management method further includes: monitoring the device's operation information after the device registration is completed.

[0077] The equipment operation information includes: equipment heartbeat, equipment logs, and equipment resources. Equipment resources include, for example, CPU (processor) utilization.

[0078] In some embodiments, the device management method further includes: notifying devices registered on the device management platform of the changed configuration information when the configuration information of the device management platform is changed.

[0079] In some embodiments, the device management method further includes: clearing useless data during the registration process. Useless data refers to data not used during the registration process. For example, during registration, data of corresponding information types is filtered according to the information acquisition format; the remaining unused data after filtering is considered useless data.

[0080] For example, in combination Figure 9 As shown, Step 11: The user fills in the device identifier of the device to be registered in the APP of the device management platform. The device management platform receives the first registration request initiated by the user and initiates the registration. Step 12: The device management platform obtains the device manufacturer, device type, and device version of the device, performs unified adaptation of the device manufacturer, device type, and device version, and obtains the registration process. Step 13: The device management platform performs preprocessing. Preprocessing includes assigning a unique device identifier to the device on the device management platform and adding the protocols and ports used in the registration process to a preset access whitelist. Step 14: Upon receiving a second registration request from the device management platform, the state machine is executed directly. Otherwise, the state machine is suspended. Suspending the state machine means storing the state machine with the unique device identifier in a preset state machine cache. Step 15: While the state machine is suspended, it waits for the device to send a third registration request to activate the state machine and continue the registration process. Step 16: The device management platform performs post-processing. The post-processing includes: clearing useless data during the registration process; monitoring the device heartbeat, device logs, and device resources; and notifying the devices registered on the device management platform of the changed configuration information when the configuration information on the device management platform is changed.

[0081] Example 2 Based on the same inventive concept, embodiments of this application provide a device management apparatus, such as... Figure 10 As shown, the device management device includes: an acquisition module 1, an assembly module 2, and a registration module 3. The acquisition module is used to acquire the attribute information of the device corresponding to the first registration request upon receiving the first registration request. The assembly module is used to assemble the registration process based on the attribute information. The registration process includes: multiple states for device registration and the transition events of each state; the transition events represent the conditions that trigger the state transition. The registration module is used to register the device using the state machine configured for the registration process.

[0082] In some embodiments, the attribute information includes: device manufacturer and device type; the assembly module 2 is used to assemble the registration process based on the attribute information in the following ways: determining the device status based on the device manufacturer; determining the device flow event based on the device type; assembling based on the status and flow event to obtain the registration process.

[0083] In some embodiments, the attribute information further includes: device version; the assembly module 2 is also used to determine the information acquisition format of the device according to the device version; the information acquisition format is used to indicate the types of information that need to be acquired in the device information; the registration process and the types of data to be acquired are assembled to obtain a new registration process.

[0084] In some embodiments, the device management apparatus further includes: a whitelist module, used to obtain the protocols and ports used in the registration process; and to add the protocols and ports to a preset access whitelist.

[0085] In some embodiments, the registration module 3 is used to register the device using the state machine of the configuration registration process in the following manner: storing the state machine in a preset state machine cache until a first preset condition is met, triggering the state machine to enter the first state in the registration process, and performing state transitions in the registration process according to the transition events; the first preset condition is receiving a second registration request from the device management platform, or receiving a third registration request from the device.

[0086] In some embodiments, the registration module 3 is used to perform state transitions in the registration process according to the transition events in the following manner: when the transition event of the current state of the state machine is triggered externally, the state machine is stored in a preset state machine cache until the transition event of the current state occurs, and the state machine is activated to continue the state transition.

[0087] In some embodiments, the device management apparatus further includes a post-processing module for monitoring device operation information after device registration is completed.

[0088] In some embodiments, the post-processing module is further configured to notify the device registered on the device management platform of the changed configuration information when the configuration information of the device management platform is changed.

[0089] It is understood that the embodiments described in Embodiment 1 are also applicable in Embodiment 2 without conflict. For the sake of brevity, they will not be repeated here.

[0090] Example 3 Combination Figure 11 As shown, this application embodiment provides a device management platform, including a processor 4 and a memory 7. Optionally, the device may further include a communication interface 5 and a bus 6. The processor 4, communication interface 5, and memory 7 can communicate with each other via the bus 6. The communication interface 5 can be used for information transmission. The processor 4 can call logical instructions in the memory 7 to execute the device management method of the above embodiment.

[0091] Furthermore, the logical instructions in the aforementioned memory 7 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium.

[0092] The memory 7, as a computer-readable storage medium, can be used to store software programs and computer-executable programs, such as program instructions / modules corresponding to the methods in the embodiments of this application. The processor 4 executes functional applications and data processing by running the program instructions / modules stored in the memory 7, thereby implementing the device management method in the above embodiments.

[0093] The memory 7 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the terminal device. Furthermore, the memory 7 may include high-speed random access memory and may also include non-volatile memory.

[0094] This application provides a storage medium storing computer-executable instructions configured to execute the aforementioned device management method.

[0095] This application provides a computer program product, which includes a computer program stored on a storage medium. The computer program includes program instructions, which, when executed by a computer, cause the computer to perform the aforementioned device management method.

[0096] The aforementioned computer-readable storage medium may be a transient computer-readable storage medium or a non-transitory computer-readable storage medium.

[0097] The technical solutions of this application embodiment can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes one or more instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the method of this application embodiment. The aforementioned storage medium can be a non-transitory storage medium, including various media capable of storing program code such as USB flash drives, portable hard drives, read-only memory, random access memory, magnetic disks, or optical disks, or it can be a transient storage medium.

[0098] The embodiments or examples disclosed herein are not exhaustive, but merely illustrative of some embodiments or examples, and are not intended to limit the scope of protection of this disclosure. Unless otherwise specified, each step in a particular embodiment or example can be implemented as an independent embodiment, and the steps can be arbitrarily combined. For example, a solution after removing some steps in a particular embodiment or example can also be implemented as an independent embodiment, and the order of the steps in a particular embodiment or example can be arbitrarily interchanged. Furthermore, optional methods or examples in a particular embodiment or example can be arbitrarily combined; moreover, embodiments or examples can be arbitrarily combined. For example, some or all steps of different embodiments or examples can be arbitrarily combined, and a particular embodiment or example can be arbitrarily combined with optional methods or examples of other embodiments or examples.

[0099] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed.

[0100] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A method for managing equipment, characterized in that, Applied to a device management platform, the method includes: Upon receiving a first registration request, obtain the attribute information of the device corresponding to the first registration request; The registration process is assembled based on the attribute information; the registration process includes: multiple states of device registration and access and transition events for each state; the transition events represent the conditions that trigger state transitions; The device is registered using the state machine configured for the registration process.

2. The method according to claim 1, characterized in that, The attribute information includes: device manufacturer and device type; the registration process is assembled based on the attribute information, including: The status of the equipment is determined according to the equipment manufacturer; Determine the flow event of the device based on the device type; The registration process is obtained by assembling the data based on the stated state and the transition events.

3. The method according to claim 2, characterized in that, The attribute information also includes: device version; the method also includes: The information acquisition format of the device is determined according to the device version; the information acquisition format is used to indicate the types of information that need to be acquired in the device information; The registration process and the information acquisition format are assembled to obtain a new registration process.

4. The method according to claim 1, characterized in that, The method further includes: Obtain the protocol and port used in the registration process; Add the protocol and port to the preset access whitelist.

5. The method according to claim 1, characterized in that, Registering the device using the state machine configured for the registration process includes: The state machine is stored in a preset state machine cache until a first preset condition is met, triggering the state machine to enter the first state in the registration process, and the state in the registration process is transitioned according to the transition event; the first preset condition is receiving a second registration request from the device management platform, or receiving a third registration request from the device.

6. The method according to claim 5, characterized in that, The state transition in the registration process is performed according to the aforementioned transition events, including: If the transition event of the current state of the state machine is triggered externally, the state machine is stored in a preset state machine cache until the transition event of the current state occurs, at which point the state machine is activated to continue the state transition.

7. The method according to claim 1, characterized in that, The method further includes: Once the device registration is complete, monitor the device's operational information.

8. The method according to claim 1, characterized in that, The method further includes: If the configuration information of the device management platform is changed, the device registered on the device management platform will be notified of the changed configuration information.

9. An equipment management device, characterized in that, The device, used in an equipment management platform, includes: The acquisition module is used to acquire the attribute information of the device corresponding to the first registration request upon receiving the first registration request. An assembly module is used to assemble a registration process based on the attribute information; the registration process includes: multiple states of device registration and access and transition events for each state; transition events characterize the conditions that trigger state transitions; The registration module is used to register the device using the state machine that configures the registration process.

10. An equipment management platform, characterized in that, The device includes a processor and a memory, the memory storing computer-executable instructions that can be executed by the processor, the processor executing the computer-executable instructions to implement the device management method according to any one of claims 1 to 8.