Communication method and device, cloud equipment, medium and program product

Abstract

The invention provides a communication method and device, equipment, a medium and a program product, relates to the technical field of communication, and is used for improving the efficiency of accessing cloud equipment by equipment with a specific technical scheme that the method comprises the following steps: receiving a communication request sent by the equipment with the specific technical scheme; based on the equipment type identifier and the communication protocol identifier, acquiring a communication protocol plug-in matched with the equipment with the body; and based on the analyzed first communication protocol and the first secret key, communicating with the equipment with the body. The method is applied to the scene that the equipment with the body accesses the cloud equipment.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of communication, and in particular, to a communication method, device, equipment, medium and program product. BACKGROUND

[0002] At present, with the rapid development of embodied intelligence technology, the application scenarios of embodied devices, such as robot dogs, wheeled robots, wearable devices, etc., are increasingly widespread. Such devices need to access a cloud platform to realize core functions such as environment perception, decision-making and control. Efficient and stable communication between embodied devices and the cloud has become a key requirement for the development of embodied intelligence.

[0003] In related technologies, embodied devices usually use manually configured private communication protocols, such as Robot Operating System (ROS) protocols, Modular Bus (Modbus) protocols, Bluetooth Low Energy (BLE) protocols, etc., to access cloud devices, so that embodied devices can interact with cloud platforms.

[0004] However, in the above method, since cloud access mainly relies on manually configured private communication protocols, the efficiency of embodied devices accessing cloud devices is low. SUMMARY

[0005] The present application provides a communication method, device, equipment, medium and program product for improving the efficiency of embodied devices accessing cloud devices.

[0006] In a first aspect, an embodiment of the present application provides a communication method, comprising: receiving a communication request sent by an embodied device, the communication request carrying at least a device type identifier and a communication protocol identifier of the embodied device; based on the device type identifier and the communication protocol identifier, obtaining a matched communication protocol plug-in of the embodied device, the communication protocol plug-in comprising a first communication protocol corresponding to the communication protocol identifier and configuration information for analyzing the first communication protocol, the communication protocol plug-in being used for analyzing the first communication protocol; based on the analyzed first communication protocol and a first key, communicating with the embodied device, the first key being determined by bidirectional authentication with the embodied device.

[0007] The technical solution provided in this application brings at least the following beneficial effects: by carrying the device type identifier and communication protocol identifier of the embodied device in the communication request, the cloud device can determine the communication protocol plugin corresponding to the embodied device. Then, the cloud device can parse the communication protocol of the embodied device based on the communication protocol plugin, thereby communicating with the embodied device. That is, the cloud device can configure and parse the communication protocol supported by the embodied device through the communication protocol plugin without manually configuring the communication protocol, thereby improving the efficiency of the embodied device accessing the cloud device.

[0008] One possible implementation, which involves obtaining a communication protocol plugin that matches the embodied device based on the device type identifier and the communication protocol identifier, includes: querying a memory dictionary table for a communication protocol plugin that matches the embodied device based on the device type identifier and the communication protocol identifier; and if the memory dictionary table does not contain a communication protocol plugin, obtaining a communication protocol plugin from a protocol plugin database based on the device type identifier and the communication protocol identifier, and loading the communication protocol plugin into the memory dictionary table.

[0009] In another possible implementation, before receiving the communication request sent by the embodied device, the method further includes: receiving an authentication request sent by the embodied device, the authentication request carrying a first ciphertext, which is obtained by the embodied device through a first private key, the first ciphertext including component information of at least one execution component in the embodied device and a first hash value containing the component information of at least one execution component; decrypting the first ciphertext using a first public key corresponding to the first private key to obtain the component information of at least one execution component and the first hash value; performing a hash operation on the component information of at least one execution component to obtain a second hash value; and if the second hash value matches the first hash value, using the first private key and the first public key as a first key, and determining that the embodied device has passed the communication authentication.

[0010] Another possible implementation, after communicating with the embodied device based on the parsed first communication protocol and first key, further includes: determining the first operating scenario in which the embodied device is located based on the operating scenario feature information sent by the embodied device; when it is detected that the historical operating scenario of the embodied device has switched to the first operating scenario, determining the first risk level corresponding to the operating scenario feature information based on the operating scenario feature information; and when the key corresponding to the first risk level is different from the second key corresponding to the historical operating scenario, updating the key for communicating with the embodied device, wherein the updated key is the key corresponding to the first risk level.

[0011] Another possible implementation is as follows: when the key corresponding to the first risk level is different from the second key corresponding to the historical operating scenario, after updating the key for communicating with the embodied device, if it is detected that the operating scenario of the embodied device has been restored to the historical operating scenario and the second key is stored in the key cache pool, and if the second key meets the first condition, then the second key is determined to be invalid; a third key is used to communicate with the embodied device, which is determined by re-verifying with the embodied device; wherein, the first condition includes any one of the following: the time interval between the creation time of the second key and the current time is greater than a preset timeout threshold, the data throughput using the second key is greater than a preset capacity threshold, or the number of failures to parse the second key is greater than a preset failure threshold.

[0012] Another possible implementation of the above method includes: if the second key does not meet the first condition, then using the second key to communicate with the embodied device.

[0013] Another possible implementation is that, after updating the key for communicating with the embodied device when the key corresponding to the first risk level is different from the second key corresponding to the historical operating scenario, the method further includes: when it is detected that the operating scenario in which the embodied device is located has been restored to the historical operating scenario and the second key is not stored in the key cache pool, a fourth key is used to communicate with the embodied device, and the fourth key is determined by re-authenticating with the embodied device.

[0014] Secondly, embodiments of this application provide a communication device, including: a receiving module, an acquiring module, and a communication module. The receiving module is used to receive a communication request sent by a avatar device, the communication request carrying at least a device type identifier and a communication protocol identifier of the avatar device. The acquiring module is used to acquire a communication protocol plugin matching the avatar device based on the device type identifier and the communication protocol identifier. The communication protocol plugin includes a first communication protocol corresponding to the communication protocol identifier and configuration information for parsing the first communication protocol. The communication module is used to communicate with the avatar device based on the parsed first communication protocol and a first key, the first key being determined through two-way authentication with the avatar device.

[0015] One possible implementation is that the aforementioned acquisition module is specifically used to query the memory dictionary table for a communication protocol plugin that matches the device based on the device type identifier and the communication protocol identifier; if the memory dictionary table does not contain a communication protocol plugin, it retrieves the communication protocol plugin from the protocol plugin database based on the device type identifier and the communication protocol identifier, and loads the communication protocol plugin into the memory dictionary table.

[0016] In another possible implementation, the communication device further includes a processing module. The receiving module is further configured to receive an authentication request sent by the embodied device before receiving a communication request sent by the embodied device. This authentication request carries a first ciphertext, which is obtained by the embodied device through a first private key. The first ciphertext includes component information of at least one execution component in the embodied device and a first hash value containing the component information of at least one execution component. The processing module is configured to decrypt the first ciphertext using a first public key corresponding to the first private key to obtain the component information of at least one execution component and the first hash value; perform a hash operation on the component information of the at least one execution component to obtain a second hash value; and if the second hash value matches the first hash value, use the first private key and the first public key as a first key, and determine that the embodied device has passed communication authentication.

[0017] In another possible implementation, the communication device further includes a processing module. The processing module is configured to: communicate with the embodied device based on the parsed first communication protocol and first key; determine the first operating scenario in which the embodied device is located based on the operating scenario feature information sent by the embodied device; and, if it detects that the embodied device's historical operating scenario has switched to the first operating scenario, determine the first risk level corresponding to the operating scenario feature information based on the operating scenario feature information; and, if the key corresponding to the first risk level is different from the second key corresponding to the historical operating scenario, update the key used for communication with the embodied device, wherein the updated key is the key corresponding to the first risk level.

[0018] In another possible implementation, the above processing module is further configured to, when the key corresponding to the first risk level is different from the second key corresponding to the historical operating scenario, update the key for communicating with the embodied device, and then, if it is detected that the operating scenario of the embodied device has been restored to the historical operating scenario and the second key is stored in the key cache pool, determine that the second key is invalid if the second key meets the first condition; and use a third key to communicate with the embodied device, the third key being determined by re-authenticating with the embodied device; wherein the first condition includes any one of the following: the time interval between the creation time of the second key and the current time is greater than a preset timeout threshold, the data throughput using the second key is greater than a preset capacity threshold, or the number of failed attempts to parse the second key is greater than a preset failure threshold.

[0019] In another possible implementation, the above processing module is also used to communicate with the embodied device using the second key if the second condition is not met.

[0020] In another possible implementation, the above processing module is further configured to update the key for communicating with the embodied device when the key corresponding to the first risk level is different from the second key corresponding to the historical operating scenario. After the updated key is the key corresponding to the first risk level, if it is detected that the operating scenario in which the embodied device is located has been restored to the historical operating scenario and the second key is not stored in the key cache pool, the fourth key is used to communicate with the embodied device. The fourth key is determined by re-authenticating with the embodied device.

[0021] Thirdly, this application provides a cloud device, which includes a processor and a memory; the memory stores a program or instructions that can run on the processor, and when the program or instructions are executed by the processor, the method described in the first aspect is implemented.

[0022] Fourthly, this application provides a readable storage medium on which a program or instructions are stored, which, when executed by a computer, implement the method of the first aspect described above.

[0023] Fifthly, this application provides a computer program product stored in a storage medium, which, when executed by a computer, implements the method described in the first aspect.

[0024] In a sixth aspect, embodiments of this application provide a chip including a processor and a communication interface, wherein the communication interface is coupled to the processor, and the processor is used to run programs or instructions to implement the method described in the first aspect.

[0025] The beneficial effects of the second to sixth aspects mentioned above are described in the corresponding description of the first aspect and will not be repeated here. Attached Figure Description

[0026] Figure 1 A network architecture diagram illustrating a communication method application provided in this application embodiment;

[0027] Figure 2 A flowchart illustrating a communication method provided in an embodiment of this application;

[0028] Figure 3 A flowchart illustrating another communication method provided in an embodiment of this application;

[0029] Figure 4 A flowchart illustrating yet another communication method provided in an embodiment of this application;

[0030] Figure 5 A flowchart illustrating yet another communication method provided in an embodiment of this application;

[0031] Figure 6A flowchart illustrating yet another communication method provided in an embodiment of this application;

[0032] Figure 7 A flowchart illustrating yet another communication method provided in an embodiment of this application;

[0033] Figure 8 A schematic diagram of the interaction flow of a communication method provided in an embodiment of this application;

[0034] Figure 9 A flowchart illustrating yet another communication method provided in an embodiment of this application;

[0035] Figure 10 This application provides a schematic diagram of the structure of a communication system according to an embodiment of the present application.

[0036] Figure 11 This is a schematic diagram of the structure of a communication device provided in an embodiment of this application;

[0037] Figure 12 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0038] The technical solutions of the embodiments of this application will be clearly described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application are within the scope of protection of this application.

[0039] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and the number of objects is not limited; for example, a first object can be one or more. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0040] The terms "at least one," "at least one of," etc., used in the specification and claims of this application refer to any one, any two, or a combination of two or more of the included items. For example, at least one of a, b, and c can mean: "a," "b," "c," "a and b," "a and c," "b and c," and "a, b, and c," where a, b, and c can be single or multiple. Similarly, "at least two" refers to two or more items, and its meaning is similar to that of "at least one."

[0041] In the description of this application, unless otherwise stated, "a plurality of" means two or more.

[0042] The communication method, apparatus, device, medium, and program product provided in this application embodiment can be applied to scenarios where a physical device accesses a cloud device.

[0043] In the field of embodied intelligence, embodied devices (such as robotic dogs, wheeled robots, and wearable devices) typically use proprietary communication protocols (such as ROS, Modbus, and BLE) for data interaction. These embodied devices need to connect to cloud devices to achieve environmental perception, decision-making, and control functions. In existing technologies, cloud access mainly relies on manually configuring protocol adapters or dedicated gateways to establish communication connections between embodied devices and cloud services. Specifically, embodied devices send data to cloud devices through a protocol stack, and the cloud receives and processes the data through a parsing module, forming a basic embodied device-cloud interaction link.

[0044] However, the aforementioned traditional solutions suffer from problems such as low access efficiency, poor automatic access capability, cumbersome protocol adaptation, and easy interruption of service communication. To solve these problems, this application introduces a microservice registry component, which treats the embodied device as a microservice and uses microservice management to solve the problems of low efficiency and poor stability of automated access for embodied devices. At the same time, a plug-in mechanism is introduced to cope with the adaptation of different communication protocols of embodied devices, which can theoretically achieve the expansion of protocols for an unlimited number of devices.

[0045] To address the aforementioned technical problems, embodiments of this application provide a communication method, apparatus, device, medium, and program product. By carrying the device type identifier and communication protocol identifier of the embodied device in the communication request, the cloud device can determine the corresponding communication protocol plugin for the embodied device. Then, the cloud device can parse the communication protocol of the embodied device based on the communication protocol plugin, thereby communicating with the embodied device. In other words, the cloud device can configure and parse the communication protocols supported by the embodied device through the communication protocol plugin without manually configuring the communication protocol, thereby improving the efficiency of the embodied device accessing the cloud device.

[0046] The communication methods, apparatus, devices, media, and program products provided in the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0047] Figure 1 This illustration shows a network architecture for a communication method application provided in an embodiment of this application. For example... Figure 1 As shown, the network architecture includes a cloud device 101 and an embodied device 102. The cloud device 101 and the embodied device 102 are interconnected.

[0048] In some embodiments, the cloud device 101 may be a server, a computer, or a processor or processing unit within a server or computer. The server may be a single server or a server cluster comprising multiple servers. It should be noted that this application embodiment does not limit the specific device form of the cloud device 101. Figure 1 The example shown is a single server, cloud device 101.

[0049] In some embodiments, the embodied device may be a mobile phone, tablet computer, laptop computer, handheld computer, in-vehicle electronic device, mobile internet device (MID), augmented reality (AR) / virtual reality (VR) device, robot, wearable device, personal computer (PC), ultra-mobile personal computer (UMPC), netbook, or personal digital assistant (PDA), etc., and the embodiments of this application do not specifically limit it. Figure 1 The example shown is a mobile phone, which is the device 102.

[0050] In some embodiments, the embodied device 102 sends a communication request to the cloud device 101, and the cloud device 101 receives the communication request sent by the embodied device. The communication request carries at least the device type identifier and communication protocol identifier of the embodied device. Then, based on the device type identifier and communication protocol identifier, the cloud device 101 obtains a communication protocol plugin that matches the embodied device. The communication protocol plugin includes a first communication protocol corresponding to the communication protocol identifier and configuration information for parsing the first communication protocol. The communication protocol plugin is used to parse the first communication protocol. Finally, the cloud device 101 communicates with the embodied device 102 based on the parsed first communication protocol and the first key.

[0051] It should be noted that the network architecture described in the embodiments of this application is for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and does not constitute a limitation on the technical solutions provided in the embodiments of this application. As network architectures evolve, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0052] See Figure 2 This is a flowchart illustrating a communication method provided in an embodiment of this application. Figure 2 As shown, the communication method provided in this application embodiment can be implemented through the cloud device described above, specifically including the following steps 201 to 203.

[0053] Step 201: The cloud device receives the communication request sent by the physical device.

[0054] In some embodiments, the communication request carries at least a device type identifier and a communication protocol identifier for the embodied device.

[0055] In some embodiments, the communication request described above may be a registration request.

[0056] In some embodiments, the communication request may also carry the software version identifier and capability description identifier of the device.

[0057] For example, the device type identifier, communication protocol identifier, software version identifier, and capability description identifier mentioned above can all be digital identifiers.

[0058] In some embodiments, the above-described capabilities may include support for motion control, lidar data transmission, etc. The specific capabilities can be determined based on actual usage requirements, and this application does not impose limitations.

[0059] In some embodiments, the device type identifier, communication protocol identifier, software version identifier, and capability description identifier may be stored in the communication request in a metadata format.

[0060] For example, the above metadata format can be:

[0061] JSON{"deviceType":"robotDog","protocol":"ROS2","capabilities":["motionControl","lidarData"]}.

[0062] Among them, deviceType represents the device type, protocol represents the communication protocol, and capabilities represent the capabilities it possesses.

[0063] In some embodiments, a cloud device can receive communication requests from a physical device to the platform through a registration process within the cloud device.

[0064] For example, the registration process in a cloud device can receive registration requests sent by the physical device through a registration interface on the platform.

[0065] For example, the registration interface mentioned above can be an HTTP interface, an HTTPS interface, or a REST interface, etc. The specific interface can be determined based on actual usage requirements, and this application embodiment does not impose any limitations.

[0066] For example, the above registration request can be {"serviceName":"unique identifier for the robot dog","ip":"device IP","port":1,"metadata":{"deviceType":"robotDog","protocol":"ROS2","capabilities":["motionControl","lidarData"]}}.

[0067] Step 202: The cloud device obtains the communication protocol plugin that matches the physical device based on the device type identifier and communication protocol identifier.

[0068] In some embodiments, the communication protocol plugin includes a first communication protocol corresponding to a communication protocol identifier and configuration information for parsing the first communication protocol. The communication protocol plugin is used to parse the first communication protocol.

[0069] In some embodiments, the cloud device can obtain a communication protocol plugin that matches the embodied device based on the device type identifier and the communication protocol identifier, provided that the embodied device has been successfully registered.

[0070] In some embodiments, when the avatar device is successfully registered, the cloud device can store the aforementioned device type identifier, communication protocol identifier, software version identifier, and capability description identifier, and establish a heartbeat mechanism with the avatar device.

[0071] It should be noted that the specific implementation process of step 202 above can be found in the description of the following embodiments, and will not be repeated here to avoid repetition.

[0072] In some embodiments, combined with Figure 2 ,like Figure 3 As shown, step 202 can be implemented through steps 202a and 202b below.

[0073] Step 202a: The cloud device queries the memory dictionary table for a matching communication protocol plugin based on the device type identifier and communication protocol identifier.

[0074] In some embodiments, the cloud device can obtain the communication protocol plugin corresponding to the device type identifier and the communication protocol identifier by traversing the memory dictionary table.

[0075] In some embodiments, if the cloud device obtains a communication protocol plugin that matches the embodied device by traversing the memory dictionary table, it can directly configure and parse the communication protocol supported by the embodied device through the communication protocol plugin that matches the embodied device stored in the memory dictionary table.

[0076] Step 202b: If the memory dictionary does not contain a communication protocol plugin, the cloud device retrieves the communication protocol plugin from the protocol plugin database based on the device type identifier and the communication protocol identifier, and loads the communication protocol plugin into the memory dictionary.

[0077] In some embodiments, the cloud device can obtain the communication protocol plugin corresponding to the device type identifier and the communication protocol identifier from the protocol plugin database based on the device type identifier and the communication protocol identifier.

[0078] For example, the above-mentioned communication protocol plugin can be a plugin Java Archive File (JAR) package.

[0079] In some embodiments, cloud devices can load plugin JAR packages in an in-memory dictionary using Java reflection. This loading employs a hot deployment mechanism, eliminating the need to restart the cloud communication service.

[0080] Step 203: The cloud device communicates with the physical device based on the parsed first communication protocol and first key.

[0081] In some embodiments, the first key is determined through two-way authentication with the embodied device.

[0082] In some embodiments, the cloud device can determine the device status of the embodied device through a health check interface, and if the device status of the embodied device is determined to be normal through the health check interface, it can communicate with the embodied device based on the parsed first communication protocol and the first key.

[0083] For example, the health check interface described above could be / health / robotDog / ros2.

[0084] For example, the cloud device listens to the health check interface of the cloud communication service by polling. If the return is not OK, data communication with the embodied device is prohibited. If the return is OK, data communication with the embodied device is allowed.

[0085] Then, if the health check interface returns an "ok" status, the cloud device can convert the message command to be executed into JSON format and send it to the embodied device.

[0086] For example, the above message instruction can be: ROS Twist message (containing linear velocity and angular velocity) {"linearVelocity":1.0,"angularVelocity":0.5}.

[0087] In the communication method provided in this application embodiment, the cloud device receives a communication request sent by the embodied device. The communication request carries at least the device type identifier and communication protocol identifier of the embodied device. Then, based on the device type identifier and communication protocol identifier, a communication protocol plugin matching the embodied device is obtained. The communication protocol plugin includes a first communication protocol corresponding to the communication protocol identifier and configuration information for parsing the first communication protocol. The communication protocol plugin is used to parse the first communication protocol. Finally, based on the parsed first communication protocol and a first key, communication is conducted with the embodied device. The first key is determined through two-way authentication with the embodied device. In this solution, by carrying the device type identifier and communication protocol identifier of the embodied device in the communication request, the cloud device can determine the communication protocol plugin corresponding to the embodied device. Then, the cloud device can parse the communication protocol of the embodied device based on the communication protocol plugin, thereby communicating with the embodied device. That is, the cloud device can configure and parse the communication protocols supported by the embodied device through the communication protocol plugin without manually configuring the communication protocol, thereby improving the efficiency of the embodied device accessing the cloud device.

[0088] In some embodiments, combined with Figure 2 ,like Figure 4 As shown, prior to step 201 above, the communication method provided in this application embodiment further includes steps 301 to 304 as described below.

[0089] Step 301: The cloud device receives the authentication request sent by the embodied device.

[0090] In some embodiments, the authentication request carries a first ciphertext, which is obtained by the embodied device through a first private key. The first ciphertext includes component information of at least one execution component in the embodied device and a first hash value containing the component information of at least one execution component.

[0091] In some embodiments, the aforementioned execution components may include at least one of the following: lidar, depth camera, inertial measurement unit (IMU), etc. The specific components can be determined according to actual usage requirements, and this application embodiment does not impose any limitations.

[0092] In some embodiments, the aforementioned component information may include at least one of the following: Media Access Control (MAC) address and serial number, etc. The specific details can be determined based on actual usage requirements, and this application embodiment does not impose any limitations.

[0093] In some embodiments, a cloud device may receive an authentication request sent by a physical device through a shared key negotiation interface.

[0094] Step 302: The cloud device decrypts the first ciphertext using the first public key corresponding to the first private key to obtain the component information of at least one execution component and the first hash value.

[0095] In some embodiments, the cloud device may decompose the decrypted first ciphertext to obtain component information of at least one execution component and a first hash value.

[0096] It should be noted that the specific decomposition process described above can be found in the descriptions in the relevant technologies, and will not be repeated here to avoid repetition.

[0097] Step 303: The cloud device performs a hash operation on the component information of at least one execution component to obtain a second hash value.

[0098] In some embodiments, the cloud device can perform a hash operation on the component information of at least one execution component using a preset hash algorithm to obtain a second hash value.

[0099] For example, the hash algorithm described above can be any of the following: MD5 algorithm, SHA-1 algorithm, SHA-256 algorithm, or SHA-512 algorithm. The specific algorithm can be determined according to actual usage requirements, and this application embodiment does not impose any limitations.

[0100] Step 304: If the second hash value matches the first hash value, the cloud device uses the first private key and the first public key as the first key and determines that the device has passed the communication authentication.

[0101] In some embodiments, the cloud device can compare the second hash value with the first hash value to determine whether the second hash value is consistent with the first hash value.

[0102] In some embodiments, after successful verification, the cloud device completes two-way verification and negotiation of a shared key group. Subsequent processes use symmetric encryption to encrypt the interface data. The specific encryption keys are classified and tiered, which alleviates the computational burden of encryption and decryption on lightweight devices while also ensuring information security in different scenarios.

[0103] In some embodiments, before the cloud device receives the authentication request sent by the avatar device, the cloud device may also receive an access request sent by the avatar device, which carries metadata information. Then, the cloud device can determine the first public key based on the metadata information.

[0104] For example, the aforementioned metadata information may include at least one of the following: device type, device model, protocol type, protocol version, encryption capability level, etc. The specific details can be determined based on actual usage requirements, and this application embodiment does not impose any limitations.

[0105] It should be noted that the above access request is an encrypted access request.

[0106] In this embodiment of the application, the cloud device can prevent the instructions sent from the cloud device to the embodied device from being tampered with, and the instructions sent from the embodied device to the cloud device from being tampered with, by performing two-way encrypted verification with the embodied device, thereby improving the security of communication between the cloud device and the embodied device.

[0107] In some embodiments, combined with Figure 2 ,like Figure 5 As shown, after step 203 above, the communication method provided in this application embodiment further includes steps 401 to 403 as described below.

[0108] Step 401: The cloud device determines the first operating scenario in which the embodied device is located based on the operating scenario feature information sent by the embodied device.

[0109] In some embodiments, the above-mentioned operational scenario feature information includes the basic risk level of the scenario in which the embodied device is currently located, the network risk level of the scenario, and the device cluster information for collaborative operations.

[0110] For example, the basic risk level of the current scenario can be any of the following: a closed park, a public street, or a high-risk work area. The specific level can be determined based on actual usage needs, and this application embodiment does not impose any limitations.

[0111] For example, the network risk level of the above scenario can be any of the following: private intranet line, public 5G, public Wi-Fi network, etc. The specific level can be determined based on actual usage needs, and this application embodiment does not impose any limitations.

[0112] It should be noted that the specific implementation process of cloud devices determining the operating scenario of a physical device through operating scenario feature information can be found in the description of relevant technologies, and will not be repeated here to avoid repetition.

[0113] Step 402: When the historical operating scenario of the embodied device is detected to have switched to the first operating scenario, the cloud device determines the first risk level corresponding to the operating scenario feature information based on the operating scenario feature information.

[0114] In some embodiments, the cloud device can calculate the first risk level based on the operating scenario feature information and the weights corresponding to the operating scenario feature information.

[0115] In some embodiments, the weights corresponding to the above-mentioned runtime scenario feature information can be preset by the cloud device; or, user-defined. The specific weights can be determined according to actual usage requirements, and this application embodiment does not impose any limitations.

[0116] For example, the cloud device can perform a weighted summation of the operating scenario feature information and the weights corresponding to the operating scenario feature information to obtain the first risk level, which can be achieved through the following formula (1).

[0117] (1)

[0118] in, The first risk level is defined as 'a', where 'a' represents the weight corresponding to the basic risk level of the scenario. 'b' represents the basic risk level of the scenario, and 'b' represents the weight corresponding to the network risk level of the scenario. Where c represents the network risk level of the scenario, and c represents the weight corresponding to the device cluster information of the collaborative operation. Information on equipment clusters working collaboratively.

[0119] Step 403: If the key corresponding to the first risk level is different from the second key corresponding to the historical operating scenario, the cloud device updates the key for communication with the embodied device.

[0120] In some embodiments, the updated key described above is the key corresponding to the first risk level.

[0121] In some embodiments, the cloud device can compare the key corresponding to the first risk level with the second key corresponding to the historical operating scenario to determine whether the key corresponding to the first risk level and the second key are the same.

[0122] It is understandable that the cloud device can update the currently used key to the key corresponding to the first risk level, and negotiate with the embodied device to use the key corresponding to the first risk level through the above two-way verification method.

[0123] For example, the cloud device can determine the corresponding encryption algorithm and key update cycle T based on the new security level. The cloud device generates a new symmetric key and updates the key using the asymmetric encryption channel negotiated during the two-way authentication phase.

[0124] In this embodiment, after the cloud device and the physical device complete the key status synchronization, the cloud device encrypts and transmits business data according to the determined security level and the corresponding symmetric key, thereby achieving strong security protection in high-risk scenarios.

[0125] In some embodiments of this application, combined with Figure 5 ,like Figure 6 As shown, after step 403 above, the communication method provided in this application embodiment further includes the following steps 501 and 502.

[0126] Step 501: If the operating scenario of the embodied device is restored to the historical operating scenario and the second key is stored in the key cache pool, and the second key meets the first condition, the cloud device determines that the updated key is invalid.

[0127] In some embodiments, the first condition includes any one of the following: the time interval between the creation time of the second key and the current time is greater than a preset timeout threshold, the data throughput using the second key is greater than a preset capacity threshold, or the number of failures to parse the second key is greater than a preset failure threshold.

[0128] For example, the aforementioned preset time limit, preset capacity threshold, and preset failure threshold can all be preset by the cloud device or customized by the user. The specific threshold can be determined according to actual usage needs, and this application embodiment does not impose any limitations.

[0129] For example, key validity verification is jointly determined based on the following three dimensions; if any one of them is satisfied, the key is determined to be invalid:

[0130] 1. Timeliness dimension: Check whether the interval between the key creation time and the current time exceeds the timeliness threshold.

[0131] 2. Data throughput dimension: Check whether the total number of historical data packets or the total number of bytes transmitted using this key exceeds the capacity threshold.

[0132] 3. Stability dimension: Check whether the number of times the device has failed to decrypt or verify integrity in recent communication history using the key exceeds the tolerance threshold.

[0133] Step 502: The cloud device communicates with the embodied device using a third key.

[0134] In some embodiments, the second key is determined by re-authenticating with the embodied device.

[0135] It should be noted that the process of the cloud device communicating with the embodied device through the third key can be found in the description of the above embodiments, and will not be repeated here to avoid repetition.

[0136] In this embodiment, after the cloud device and the physical device complete the key status synchronization, the cloud device encrypts and transmits the business data according to the determined security level and the corresponding symmetric key. This achieves strong security protection in high-risk scenarios while ensuring computational efficiency and smooth communication in low-risk, repetitive scenarios.

[0137] In some embodiments, the communication method provided in this application further includes the following step 601.

[0138] Step 601: If the second key does not meet the first condition, the cloud device uses the second key to communicate with the embodied device.

[0139] It is understandable that even if the second key does not meet the first condition, the cloud device can continue to communicate with the embodied device through the second key.

[0140] For example, if the cloud device determines that the second key has not expired, it directly reuses the second key as the current session key and notifies the embodied device to switch to the second key through a simplified handshake instruction, thereby avoiding repeated asymmetric encryption operations and reducing communication latency.

[0141] In some embodiments, combined with Figure 5 ,like Figure 7 As shown, after step 403 above, the communication method provided in this application embodiment further includes step 701 as described below.

[0142] Step 701: If the operating scenario of the embodied device is detected to have been restored to the historical operating scenario and the second key is not stored in the key cache pool, the cloud device uses the fourth key to communicate with the embodied device.

[0143] In some embodiments, the fourth key is determined by re-authenticating with the embodied device.

[0144] In this embodiment, after the cloud device and the physical device complete the key status synchronization, the cloud device encrypts and transmits the business data according to the determined security level and the corresponding symmetric key. This achieves strong security protection in high-risk scenarios while ensuring computational efficiency and smooth communication in low-risk, repetitive scenarios.

[0145] The following section provides a detailed explanation of the interaction process between a cloud device and a physical device. This can be achieved through steps 1 to 5 below.

[0146] Step 1: When the embodied device starts up, it obtains the environment information of the cloud device configured in the firmware.

[0147] For example, the aforementioned environmental information includes the IP address and protocol version number of the cloud device. The specific details can be determined based on actual usage requirements, and this application embodiment does not impose any limitations.

[0148] Step 2: The embodied device collects device metadata, encrypts it using the built-in private key, and sends an access request to the cloud device according to the protocol supported by the queried cloud service.

[0149] For example, the aforementioned device metadata includes information such as device type, device model, protocol type, protocol version, and encryption capability level.

[0150] For example, the access request carries the aforementioned device metadata.

[0151] Step 3: The cloud device receives the access request sent by the embodied device, queries the public key of the embodied device stored in the cloud device based on the device metadata, then decrypts the device metadata, obtains the device metadata, and starts the two-way authentication process.

[0152] Step 4: After two-way authentication is completed and the two parties have negotiated the communication key, the access registration process will begin.

[0153] Step 5: During use, the cloud device uses scene awareness to dynamically manage the communication key with security hierarchy, ensuring the system's communication efficiency and security.

[0154] For example, such as Figure 8 As shown below, the specific interaction process will be explained in detail to illustrate the above two-way authentication process. This can be achieved through steps 10 to 20 below.

[0155] Step 10: Collect information on core components using the device.

[0156] For example, the embodied device can collect information about the core components through software or hardware interfaces.

[0157] For example, the information of the aforementioned core components includes: MAC addresses, serial numbers, and other information of core components such as lidar, depth cameras, and IMUs.

[0158] Step 11: Organize authentication information using the device.

[0159] For example, the embodied device combines the information collected from the core components according to rules to form device information data.

[0160] For example, embodied devices use a sorting and fixed pairing rule to combine information from core components, as follows:

[0161] Assume the embodied device has n core components, Let n represent the information of the i-th core component, where n is a positive integer. First, sort the information of the n components according to their sequence numbers. Without loss of generality, let the sorting result be... , , , Secondly, the n components are divided into n / 2 groups according to information similarity, with two components in each group. and The information for each group is generated using the XOR operation. After obtaining n / 2 pieces of information data, the n / 2 pieces of information are directly concatenated to form the device's authentication information, DeviceInfo.

[0162] Step 12: The device encrypts the authentication information.

[0163] For example, the embodied device generates a token from the generated authentication information DeviceInfo and the device itself. This application uses a real-time token method that combines timeliness and authentication for encryption. The rules and procedures are as follows:

[0164] First, the device combines DeviceInfo, device serial number, current timestamp, and random number into a single string using a '|' separator: DeviceAllInfo = DeviceInfo|Device Serial Number|Current Timestamp|Random Number. Then, it performs a hash operation on DeviceAllInfo to obtain a hash value: DeviceHash = SHA-256(DeviceAllInfo). Next, it concatenates DeviceAllInfo and DeviceHash to get DeviceAllInfoPlus = DeviceAllInfo|DeviceHash. Finally, it encrypts the generated information using a private key: Token = SM2(DeviceAllInfoPlus, private_key).

[0165] Step 13: The embodied device sends encrypted authentication information to the cloud device.

[0166] For example, the embodied device sends encrypted authentication information to the cloud device through a shared key negotiation interface.

[0167] Step 14: The cloud device receives the encrypted authentication information sent by the physical device.

[0168] Step 15: Decrypt the encrypted authentication information from the cloud device, collect the core component information of the physical device based on the decrypted authentication information, and verify the information.

[0169] For example, when a cloud device receives encrypted authentication information, it first decrypts the encrypted authentication information using the public key corresponding to the device, i.e., DeviceAllInfoPlus = SM2(Token, public_key). Then, it decomposes DeviceAllInfoPlus to obtain DeviceAllInfo and DeviceHash. By hashing DeviceAllInfo, the result is compared with DeviceHash. If they match, the verification is successful; otherwise, the verification fails. Finally, the cloud device connects to the proxy module to obtain the verified device serial number.

[0170] Step 16: The cloud device collects the core component information of the physical device and organizes and encrypts the authentication information.

[0171] For example, the cloud device extracts information about the core components of the embodied device from the database and generates the same encrypted authentication information according to steps 11 and 12 above.

[0172] Step 17: The cloud device sends encrypted authentication information to the embodied device.

[0173] Step 18: The embodied device receives the encrypted authentication information sent by the cloud device.

[0174] Step 19: The device decrypts the encrypted authentication information.

[0175] Step 20: The device verifies the decrypted authentication information. If they match, the two-way authentication is successful; otherwise, the two-way authentication fails.

[0176] It should be noted that the specific process of the device verifying the decrypted authentication information can be found in step 15 above, and will not be repeated here to avoid repetition.

[0177] For example, such as Figure 9 As shown below, the access registration process provided in this application embodiment will be explained in detail. Specifically, it can be implemented through steps 30 to 37 below.

[0178] Step 30: Collect information on the device's capabilities.

[0179] For example, the aforementioned capability information includes device type (e.g., "machine dog"), software version, communication protocol (e.g., "ROS2"), and capability description (e.g., "supports motion control, LiDAR data transmission"), etc.

[0180] Step 31: The physical device sends a registration request to the cloud device.

[0181] For example, the above registration request carries capability information.

[0182] Step 32: The cloud device receives the registration request sent by the physical device.

[0183] Step 33: The cloud device records the newly registered device type and protocol, and establishes a heartbeat mechanism with the embodied device.

[0184] Step 34: The cloud device searches the memory dictionary table for a corresponding communication protocol plugin for the device based on its type and protocol.

[0185] For example, if it is determined that a communication protocol plugin exists in the memory dictionary table, step 36 is executed; or, if it is determined that a communication protocol plugin exists in the memory dictionary table, step 35 is executed.

[0186] Step 35: Based on the device type and protocol, the cloud device dynamically downloads the corresponding device and protocol parsing plugin JAR package from the plugin repository to the cloud communication service.

[0187] Step 36: The cloud device determines the device status of the physical device based on the health detection interface.

[0188] Step 37: When the device status of the embodied device is normal, the cloud device sends out an extension plugin to communicate with the embodied device through the extension plugin.

[0189] In some embodiments, the embodied device can also listen to the health check interface of the cloud communication service by polling. If the return value is not OK, data communication with the cloud is prohibited; if the return value is OK, data communication with the cloud is allowed. Then, after the health check in the previous step passes, the embodied device can download the extension plugin through the extension plugin download interface of the cloud communication service. If the plugin is available, the plugin JAR package is hot-loaded using Java reflection, without needing to restart the agent module.

[0190] It should be noted that the above-described method embodiments, or the various possible implementations of the method embodiments, can be executed individually, or, provided there is no conflict, they can be combined with each other. The specific implementation can be determined according to actual usage requirements, and this application embodiment does not impose any restrictions on this.

[0191] Figure 10 This is a schematic diagram of the structure of a communication system provided in an embodiment of this application. Figure 10As shown, the communication system 800 may include: a device-side proxy module 801 and a cloud device access proxy module 802. The device-side proxy module 801 includes: a key management module 8011, an encryption / decryption algorithm module 8012, and a plugin management and operation support module 8013. The cloud device access proxy module 802 includes: a registration center 8021, an encryption / decryption algorithm module 8022, a plugin repository 8023, and a key management and policy center 8024.

[0192] The device-side agent module 801 is a software component embedded in the firmware or operating system of a smart device. It possesses core component information collection capabilities, protocol conversion capabilities, metadata reporting capabilities, and encryption / decryption capabilities.

[0193] The key management module 8011 is used for the storage and lifecycle management of local private keys and symmetric keys on the device.

[0194] The device-side encryption / decryption algorithm module 8012 is used for implementing symmetric and asymmetric encryption / decryption algorithms, such as SM2 and SM3, on the device side.

[0195] Plugin Management and Operation Support 8013 is used for managing plugins downloaded from the platform and supporting the dynamic loading and operation of these plugins on the device.

[0196] The cloud device access proxy module 802 corresponds to the device-side proxy module 801 and is a software component used in the cloud to handle heterogeneous device proxying. It has the capabilities of interface connection, data collection, command issuance, and encryption / decryption operations.

[0197] Registration Center 8021 is used to manage the registration information, status, and subscription events of device instances.

[0198] Plugin repository 8023 is used to store communication protocol parsing plugins and extension plugins for various devices.

[0199] The Key Management and Policy Center 8024 is responsible for key management for two-way authentication, verification of core component information, scenario risk assessment, and dynamic key updates.

[0200] The encryption / decryption algorithm module 8022 is used for cloud-based implementation of symmetric and asymmetric encryption / decryption algorithms, such as SM2 and SM3.

[0201] It should be noted that for a detailed explanation of the steps performed by each module and their beneficial effects, please refer to the description in the above embodiments, which will not be repeated here.

[0202] As can be seen, the above mainly describes the solutions provided by the embodiments of this application from a methodological perspective. To achieve the above functions, the embodiments of this application provide corresponding hardware structures and / or software modules for executing each function. Those skilled in the art should readily recognize that, in conjunction with the modules and algorithm steps of the various examples described in the embodiments disclosed herein, the embodiments of this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0203] This application embodiment can divide the communication device into functional modules according to the above method example. For example, each function can be divided into its own functional module, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware or as a software functional module. Optionally, the module division in this application embodiment is illustrative and only represents one logical functional division; other division methods may be used in actual implementation.

[0204] In some embodiments, this application also provides a communication device. The communication device may include one or more functional modules for implementing the communication methods of the above method embodiments.

[0205] For example, Figure 11 This is a schematic diagram of a communication device provided in an embodiment of this application. Figure 11 As shown, the communication device 900 includes: a receiving module 901, an acquisition module 902, and a communication module 903.

[0206] The receiving module 901 is used to receive a communication request sent by the avatar device, which carries at least a device type identifier and a communication protocol identifier of the avatar device. The obtaining module 902 is used to obtain a communication protocol plugin matching the avatar device based on the device type identifier and the communication protocol identifier. This communication protocol plugin includes a first communication protocol corresponding to the communication protocol identifier and configuration information for parsing the first communication protocol. The communication module 903 is used to communicate with the avatar device based on the parsed first communication protocol and a first key, where the first key is determined through two-way authentication with the avatar device.

[0207] In the communication device provided in this application, by carrying the device type identifier and communication protocol identifier of the embodied device in the communication request, the communication device can determine the communication protocol plugin corresponding to the embodied device. Then, the communication device can parse the communication protocol of the embodied device based on the communication protocol plugin, thereby communicating with the embodied device. That is, the communication device can configure and parse the communication protocol supported by the embodied device through the communication protocol plugin, without the need for manual configuration of the communication protocol, thereby improving the efficiency of the embodied device accessing the communication device.

[0208] In some embodiments, the acquisition module 902 is specifically used to query a communication protocol plugin that matches the device in a memory dictionary table based on the device type identifier and the communication protocol identifier; if the memory dictionary table does not contain a communication protocol plugin, the module retrieves a communication protocol plugin from a protocol plugin database based on the device type identifier and the communication protocol identifier, and loads the communication protocol plugin into the memory dictionary table.

[0209] In some embodiments, the communication device 900 further includes a processing module. The receiving module 901 is further configured to receive an authentication request sent by the embodied device before receiving a communication request sent by the embodied device. This authentication request carries a first ciphertext, which is obtained by the embodied device through encryption using a first private key. The first ciphertext includes component information of at least one execution component in the embodied device and a first hash value containing the component information of at least one execution component. The processing module is configured to decrypt the first ciphertext using a first public key corresponding to the first private key to obtain the component information of at least one execution component and the first hash value; perform a hash operation on the component information of the at least one execution component to obtain a second hash value; and if the second hash value matches the first hash value, use the first private key and the first public key as a first key, and determine that the embodied device has passed communication authentication.

[0210] In some other embodiments, the communication device 900 further includes a processing module. The processing module is configured to, after communicating with the embodied device based on the parsed first communication protocol and first key, determine the first operating scenario in which the embodied device is located based on the operating scenario feature information sent by the embodied device; and, if it is detected that the embodied device's historical operating scenario has switched to the first operating scenario, determine the first risk level corresponding to the operating scenario feature information based on the operating scenario feature information; and, if the key corresponding to the first risk level is different from the second key corresponding to the historical operating scenario, update the key used for communication with the embodied device, wherein the updated key is the key corresponding to the first risk level.

[0211] In some other embodiments, the above-mentioned processing module is further configured to, when the key corresponding to the first risk level is different from the second key corresponding to the historical operating scenario, update the key for communicating with the embodied device, and then, if it is detected that the operating scenario of the embodied device has been restored to the historical operating scenario and the second key is stored in the key cache pool, determine that the second key is invalid if the second key meets the first condition; and use a third key to communicate with the embodied device, the third key being determined by re-performing two-way authentication with the embodied device; wherein the first condition includes any one of the following: the time interval between the creation time of the second key and the current time is greater than a preset timeout threshold, the data throughput using the second key is greater than a preset capacity threshold, or the number of failed attempts to parse the second key is greater than a preset failure threshold.

[0212] In some other embodiments, the above-described processing module is further configured to communicate with the embodied device using a second key if the second condition is not met.

[0213] In some other embodiments, the above-mentioned processing module is further configured to update the key for communicating with the embodied device when the key corresponding to the first risk level is different from the second key corresponding to the historical operating scenario. After the updated key is the key corresponding to the first risk level, when it is detected that the operating scenario in which the embodied device is located has been restored to the historical operating scenario and the second key is not stored in the key cache pool, the fourth key is used to communicate with the embodied device. The fourth key is determined by re-authenticating with the embodied device.

[0214] It should be noted that the communication device can implement all the processes implemented in the above method embodiments and achieve the same beneficial effects. To avoid repetition, it will not be described again here.

[0215] In the case where the functions of the integrated modules described above are implemented in hardware, this application provides a possible structural schematic diagram of the electronic device involved in the above embodiments. For example... Figure 12 As shown, the electronic device 90 includes: a processor 92, a communication interface 93, and a bus 94. Optionally, the electronic device 90 may also include a memory 91.

[0216] Processor 92 may implement or execute various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. Processor 92 may be a central processing unit, a general-purpose processor, a digital signal processor, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It may implement or execute various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. Processor 92 may also be a combination that implements computational functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

[0217] Communication interface 93 is used to connect with other devices via a communication network. This communication network can be Ethernet, wireless access network, wireless local area network (WLAN), etc.

[0218] The memory 91 may be a read-only memory (ROM) or other type of static storage device capable of storing static information and instructions, random access memory (RAM) or other type of dynamic storage device capable of storing information and instructions, or electrically erasable programmable read-only memory (EEPROM), disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but is not limited thereto.

[0219] In one possible implementation, the memory 91 can exist independently of the processor 92. The memory 91 can be connected to the processor 92 via a bus 94 and is used to store instructions or program code. When the processor 92 calls and executes the instructions or program code stored in the memory 91, it can implement the communication method provided in the embodiments of this application.

[0220] In another possible implementation, memory 91 can also be integrated with processor 92.

[0221] Bus 94 can be an Extended Industry Standard Architecture (EISA) bus, etc. Bus 94 can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 12 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0222] Through the above description of the implementation methods, those skilled in the art can clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the service calling device can be divided into different functional modules to complete all or part of the functions described above.

[0223] This application embodiment also provides a chip, which includes a processor and a communication interface. The communication interface is coupled to the processor. The processor is used to run programs or instructions to implement the various processes of the above-described communication method embodiments and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0224] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0225] This application also provides a readable storage medium storing a program or instructions that, when executed by a computer, implement the communication method provided in the above embodiments. It is understood that all or part of the processes in the above method embodiments can be executed by computer instructions instructing related hardware; the readable storage medium can be any of the foregoing embodiments or memory; the readable storage medium can also be an external storage device of the service invocation device, such as a plug-in hard drive, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the service invocation device. Further, the readable storage medium can include both internal storage units of the service invocation device and external storage devices. The readable storage medium is used to store the computer program and other programs and data required by the service invocation device. The readable storage medium can also be used to temporarily store data that has been output or will be output.

[0226] This application also provides a computer program product, which is stored in a storage medium and implements the communication method provided in the above embodiments when executed by a computer.

[0227] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0228] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a computer software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0229] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A communication method, characterized in that, Applied to cloud devices, including: Receive a communication request sent by the avatar device, the communication request carrying at least the device type identifier and communication protocol identifier of the avatar device; Based on the device type identifier and the communication protocol identifier, a communication protocol plugin matching the physical device is obtained. The communication protocol plugin includes a first communication protocol corresponding to the communication protocol identifier and configuration information for parsing the first communication protocol. The communication protocol plugin is used to parse the first communication protocol. Based on the parsed first communication protocol and first key, communication is conducted with the avatar device, wherein the first key is determined through two-way authentication with the avatar device.

2. The communication method according to claim 1, characterized in that, The step of obtaining a communication protocol plugin that matches the specific device based on the device type identifier and the communication protocol identifier includes: Based on the device type identifier and the communication protocol identifier, query the memory dictionary table for a communication protocol plugin that matches the embodied device; If the communication protocol plugin is not included in the memory dictionary table, the communication protocol plugin is retrieved from the protocol plugin database based on the device type identifier and the communication protocol identifier, and then loaded into the memory dictionary table.

3. The communication method according to claim 1 or 2, characterized in that, Before receiving the communication request sent by the embodied device, the method further includes: The device receives an authentication request sent by the embodied device. The authentication request carries a first ciphertext, which is obtained by the embodied device through a first private key. The first ciphertext includes component information of at least one execution component in the embodied device and a first hash value containing the component information of the at least one execution component. The first ciphertext is decrypted using the first public key corresponding to the first private key to obtain the component information of the at least one execution component and the first hash value; A hash operation is performed on the component information of the at least one execution component to obtain a second hash value; If the second hash value matches the first hash value, the first private key and the first public key are used as the first key, and the embodied device is determined to have passed communication authentication.

4. The communication method according to claim 1, characterized in that, After communicating with the embodied device based on the parsed first communication protocol and first key, the method further includes: Based on the operational scenario feature information sent by the avatar device, the first operational scenario in which the avatar device is located is determined; If the historical operating scenario of the avatar device is detected to switch to the first operating scenario, a first risk level corresponding to the operating scenario feature information is determined based on the operating scenario feature information. If the key corresponding to the first risk level is different from the second key corresponding to the historical operating scenario, the key for communicating with the avatar device is updated, and the updated key is the key corresponding to the first risk level.

5. The communication method according to claim 4, characterized in that, When the key corresponding to the first risk level is different from the second key corresponding to the historical operating scenario, after updating the key for communicating with the embodied device, the method further includes: If the operating scenario of the avatar device is restored to the historical operating scenario and the second key is stored in the key cache pool, then if the second key meets the first condition, the second key is determined to be invalid. The third key is used to communicate with the avatar device, and the third key is determined by re-authenticating with the avatar device; The first condition includes any one of the following: the time interval between the creation time of the second key and the current time is greater than a preset timeliness threshold, the data throughput using the second key is greater than a preset capacity threshold, or the number of failed attempts to parse the second key is greater than a preset failure threshold.

6. The communication method according to claim 5, characterized in that, The method further includes: If the second key does not meet the first condition, then the second key is used to communicate with the avatar device.

7. The communication method according to claim 4, characterized in that, When the key corresponding to the first risk level is different from the second key corresponding to the historical operating scenario, after updating the key for communicating with the embodied device, the method further includes: If the operating scenario of the avatar device is detected to have returned to the historical operating scenario and the second key is not stored in the key cache pool, the fourth key is used to communicate with the avatar device. The fourth key is determined by re-authenticating with the avatar device.

8. A communication device, characterized in that, Applied to cloud devices, including: receiving module, acquisition module and communication module; The receiving module is used to receive a communication request sent by the avatar device, the communication request carrying at least the device type identifier and communication protocol identifier of the avatar device; The acquisition module is used to acquire a communication protocol plugin that matches the device based on the device type identifier and the communication protocol identifier. The communication protocol plugin includes a first communication protocol corresponding to the communication protocol identifier and configuration information for parsing the first communication protocol. The communication protocol plugin is used to parse the first communication protocol. The communication module is used to communicate with the avatar device based on the parsed first communication protocol and the first key, wherein the first key is determined through two-way authentication with the avatar device.

9. A cloud device, characterized in that, It includes a processor and a memory, the memory storing a program or instructions that can run on the processor, the program or instructions being executed by the processor to implement the communication method as described in any one of claims 1-7.

10. A readable storage medium, characterized in that, The readable storage medium stores a program or instructions that, when executed by a computer, implement the communication method as described in any one of claims 1-7.

11. A computer program product, characterized in that, The computer program product is stored in a storage medium, and when executed by a computer, the computer program product implements the communication method as described in any one of claims 1-7.

Images