Access method, device, resource management system and related device of physical device

Abstract

The application provides an access method and device of a physical device, a resource management system and related equipment; is applied to a cloud platform including multiple bridge groups and multiple cloud services, each bridge group including multiple bridge services; the method includes: allowing a bridge group to establish a connection with a preset corresponding physical device; when receiving a device message sent by any physical device, each bridge service in the bridge group corresponding to each connection of any physical device respectively acquires different device messages and reports to the cloud service; when the cloud service generates a service instruction, determines the physical device pointed to by each service instruction, and respectively sends to the corresponding bridge group, allowing each bridge service in each bridge group receiving the service instruction to respectively acquire different service instructions and forward to the respective connected physical device. It can be seen that the method realizes access of a large number of physical devices to the cloud platform and improves the throughput capacity of the cloud platform message.

Description

Technical Field

[0001] The embodiments of this application relate to the technical field of the Internet of Things (IoT), and more particularly to a method, apparatus, resource management system, and related equipment for accessing physical devices. Background Technology

[0002] In the physical device access methods of related cloud platforms, only a single message queue middleware or a single intermediary server is often used to access physical devices. Therefore, the access capability of physical devices and the message throughput of the cloud platform are extremely limited by the message throughput capability of the message queue middleware or the single intermediary server.

[0003] Therefore, a solution is needed to improve the access capability and message throughput of physical devices. Summary of the Invention

[0004] In view of this, the purpose of this application is to provide a method, apparatus, resource management system and related equipment for accessing physical devices.

[0005] For the purposes described above, this application provides a method for accessing physical devices.

[0006] The cloud platform includes at least one bridging group and multiple cloud services, with each bridging group including at least one bridging service;

[0007] The method includes:

[0008] The at least one bridging group establishes a connection with a preset corresponding physical device;

[0009] In response to receiving at least one device message from any physical device, the system obtains different device messages through each bridging service in the bridging group corresponding to each physical device and reports them to any cloud service.

[0010] In response to any cloud service generating at least one service instruction, the physical device to which each service instruction points is determined, and each service instruction is sent to the bridge group connected to the physical device to which it points. Each bridge service in each bridge group receiving the service instruction obtains a different service instruction and forwards it to the physical device to which it is connected.

[0011] Furthermore, the cloud platform also includes multiple primary intermediary servers;

[0012] The step of establishing a connection between the at least one bridging group and a preset corresponding physical device includes:

[0013] Connect a first intermediary server to each bridging group, and connect the first intermediary server to all physical devices corresponding to the bridging group.

[0014] Each first intermediary server connects to each bridge service in the corresponding bridge group.

[0015] Furthermore, different device messages are obtained through each bridging service in the bridging group corresponding to each of the aforementioned physical devices, including:

[0016] The first intermediary server receives at least one device message from the corresponding physical device and publishes the at least one device message to the corresponding bridging group.

[0017] Each bridging service in the corresponding bridging group shall obtain device messages from the first intermediary server using a publish-subscribe messaging paradigm.

[0018] Furthermore, each bridging service in the corresponding bridging group is instructed to obtain device messages from the first intermediary server using a publish-subscribe messaging paradigm, including:

[0019] Set the same bridge group name for each bridge service in the same bridge group;

[0020] In response to each bridging service in the same bridging group subscribing to various device messages published by the first intermediary server using the same bridging group name, each bridging service receives different device messages.

[0021] Furthermore, the cloud platform also includes multiple secondary intermediary servers;

[0022] The reporting to any cloud service includes:

[0023] The at least one bridging group is connected to the same second intermediary server, and each second intermediary server is connected to various cloud services;

[0024] Each bridging service sends its respective device message to the second intermediary server for the corresponding connection;

[0025] Set the same service group name for each cloud service;

[0026] In response to each second intermediary server publishing device messages to each cloud service, and each cloud service subscribing to each device message using the same service group name, each cloud service receives different device messages.

[0027] Furthermore, after connecting the at least one bridging group to the same second intermediary server, the method further includes:

[0028] Each bridging group stores and maintains the mapping relationships between itself and the corresponding first intermediary server, the corresponding second intermediary servers, and the corresponding physical devices.

[0029] The mapping relationship is then stored in each cloud service.

[0030] Furthermore, the service instruction includes the device label of the physical device to which it is directed;

[0031] The step of sending each service instruction to the bridge group connected to its respective physical device includes:

[0032] The cloud service is instructed to determine the second intermediary server and the corresponding first intermediary server corresponding to the device tag according to the mapping relationship;

[0033] The cloud service adds the first intermediary tag of the corresponding first intermediary server to the service instruction to obtain the tag instruction, and sends it to the corresponding second intermediary server.

[0034] The second intermediary server is instructed to issue the tag instruction to the corresponding bridging service group according to the first intermediary tag.

[0035] Furthermore, each bridging service in each bridging group receiving the service instruction obtains a different service instruction, including:

[0036] In response to each bridging service in the same bridging group subscribing to the tag instruction published by the second intermediary server using the same bridging group name, each bridging service receives a different tag instruction.

[0037] Remove the first intermediary tag added in the tag instruction from each bridging service to obtain the service instruction.

[0038] Furthermore, the data is forwarded to the respective connected physical devices, including:

[0039] The service instruction is sent to the first intermediary server corresponding to the first intermediary tag;

[0040] The corresponding first intermediary server is instructed to send the service instruction to the physical device connected to the first intermediary server according to the device tag.

[0041] Furthermore, the cloud platform also includes load balancing services;

[0042] The step of establishing a connection between the at least one bridging group and a preset corresponding physical device further includes:

[0043] The load balancing service is connected to all physical devices outside the cloud platform and to all first intermediary servers;

[0044] The load balancing service receives device messages from each physical device and sends the received device messages to the corresponding first intermediary server.

[0045] The load balancing service receives service instructions from each of the first intermediary servers and sends the received service instructions to the corresponding physical devices.

[0046] Furthermore, at least one physical device includes at least one second physical device, the second physical device running at least one first application;

[0047] The cloud platform connects to each of the second physical devices according to the physical device access method described above, receives device messages from each first application, and sends service instructions to the corresponding first application.

[0048] Based on the same inventive concept, this application also provides an access device for a physical device, including: a connection module, an uplink module, and a downlink module;

[0049] The connection module is configured to enable at least one bridging group to establish a connection with a preset corresponding physical device.

[0050] The uplink module is configured to, in response to receiving at least one device message from any physical device, obtain different device messages through each bridging service in the bridging group corresponding to each physical device, and report them to any cloud service.

[0051] The downlink module is configured to, in response to any cloud service generating at least one service instruction, determine the physical device to which each service instruction points, send each service instruction to the bridge group connected to the physical device to which it points, and cause each bridge service in each bridge group receiving the service instruction to obtain different service instructions and forward them to the physical device to which it is connected.

[0052] Based on the same inventive concept, this application also provides a resource integration system, including at least one physical device and at least one access device for the physical device as described above, wherein each physical device is connected to the access device;

[0053] In response to the at least one physical device sending at least one device message to the access device, the access device is instructed to execute the physical device access method as described in any of the above items to access each physical device and receive each device message;

[0054] In response to the access device performing the physical device access method as described above, at least one service instruction is sent to at least one physical device, causing each physical device to receive the corresponding service instruction.

[0055] Based on the same inventive concept, this application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the access method of the physical device as described in any of the above.

[0056] Based on the same inventive concept, this application also provides a non-transitory computer-readable storage medium, wherein the non-transitory computer-readable storage medium stores computer instructions for causing the computer to perform the access method of the physical device as described above.

[0057] As can be seen from the above, the physical device access method, apparatus, resource management system, and related equipment provided in this application, based on multiple bridging groups and multiple bridging services in each bridging group, not only consider the need to handle a large number of device accesses and a large number of message accesses simultaneously when devices access the cloud platform, but also consider the need for the cloud platform's cloud services to handle a large number of message accesses without simultaneously handling a large number of device accesses when interacting with device messages and service commands. Based on the comprehensive consideration of the above two points, multiple first intermediary servers and multiple second intermediary servers are set up. When each first intermediary server and each second intermediary service interacts with multiple bridging services, the publish-subscribe messaging paradigm is used so that each bridging service can obtain different device messages and service commands, maximizing the utilization of the computing power of each bridging service, thereby enabling a large number of devices to access the cloud platform and improving the message throughput of the cloud platform. Attached Figure Description

[0058] To more clearly illustrate the technical solutions in this application or related technologies, the drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0059] Figure 1 This is an architecture diagram of the cloud platform according to an embodiment of this application;

[0060] Figure 2 This is a schematic diagram of the uplink messages of the cloud platform in an embodiment of this application;

[0061] Figure 3 This is a schematic diagram of the uplink messages of the cloud platform in an embodiment of this application;

[0062] Figure 4 This is a flowchart of a physical device access method according to an embodiment of this application;

[0063] Figure 5 This is a schematic diagram of the access device structure of the physical device according to an embodiment of this application;

[0064] Figure 6 This is a schematic diagram of the electronic device structure according to an embodiment of this application. Detailed Implementation

[0065] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with specific embodiments and the accompanying drawings.

[0066] It should be noted that, unless otherwise defined, the technical or scientific terms used in the embodiments of this application should have the ordinary meaning understood by one of ordinary skill in the art to which this application pertains. The terms "first," "second," and similar terms used in the embodiments of this application do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Terms such as "comprising" or "including" mean that the element or object preceding the word encompasses the elements or objects listed following the word and their equivalents, without excluding other elements or objects. Terms such as "connected" or "linked" are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. Terms such as "upper," "lower," "left," and "right" are only used to indicate relative positional relationships; when the absolute position of the described object changes, the relative positional relationship may also change accordingly.

[0067] As described in the background section, the access methods for related physical devices are still insufficient to meet the needs of actual IoT interactions.

[0068] In the process of implementing this application, the applicant discovered that the main problem with the access methods for related physical devices is that the access methods for related physical devices often only use a single message queue middleware or a single intermediary server to access the devices.

[0069] Therefore, the device's access capabilities and the message throughput of the cloud platform are extremely limited by the message queue middleware or the message throughput capacity of a single intermediary server.

[0070] Based on this, one or more embodiments of this application provide a method for accessing physical devices, which enables the access of a large number of devices based on multiple sets of bridging services and multiple intermediary servers, and improves the information throughput to accommodate the large amount of interactive information brought about by the access of a large number of devices.

[0071] The embodiments of this application are described in detail below with reference to the accompanying drawings.

[0072] In embodiments of this application, the cloud platform includes multiple bridging groups and multiple cloud services, wherein each bridging group may include multiple bridging services.

[0073] In some other embodiments, the cloud platform may also include multiple first intermediary servers and multiple second intermediary servers.

[0074] In this embodiment, with Figure 1 The architecture of the cloud platform shown is a concrete example, such as Figure 1 As shown, the cloud platform is equipped with bridging group 1, bridging group 2, bridging group 3 and bridging group 4; it also has 3 remote services, which are represented as IoT service 1, IoT service 2 and IoT service 3 respectively.

[0075] Each bridging group has two bridging services for data bridging. The bridging services in bridging group 1 are denoted as MQTT-MQ-Bridge11-1 and MQTT-MQ-Bridge11-2; the bridging services in bridging group 2 are denoted as MQTT-MQ-Bridge21-1 and MQTT-MQ-Bridge21-2; the bridging services in bridging group 3 are denoted as MQTT-MQ-Bridge32-1 and MQTT-MQ-Bridge32-2; and the bridging services in bridging group 4 are denoted as MQTT-MQ-Bridge42-1 and MQTT-MQ-Bridge42-2.

[0076] Furthermore, in Figure 1 In the example, the same number of MQTT Brokers as the bridging group are also set up, that is, the first intermediary server, which are referred to as MQTT Broker1, MQTT Broker2, MQTT Broker3 and MQTTBroker4 respectively.

[0077] Furthermore, in Figure 1 In the example, there are also two MQ Brokers, that is, the second intermediary servers, which are referred to as MQ Broker1 and MQ Broker2 respectively.

[0078] In this embodiment, MQ stands for Message Queue, and MQTT stands for Message Queue Telemetry Transport Protocol, which is a message protocol based on the publish-subscribe model.

[0079] Among them, message queues (MQ) are suitable for message communication and data interaction between services, and are suitable for a small number of terminal accesses, that is, the access of services at both ends of the MQ Broker, but with a large read and write throughput; while the MQTT protocol is lightweight and is characterized by low latency and high concurrency access of a large number of devices, making it suitable for terminal-to-cloud access and data transmission.

[0080] Publish-subscribe is a messaging paradigm where the sender of a message is called a publisher. Publishers do not send messages directly to specific recipients, also known as subscribers. Instead, they categorize published messages into different types without needing to know which subscribers might exist. Similarly, subscribers can express interest in one or more categories and only receive messages that interest them, without needing to know which publishers exist.

[0081] Based on this, the first intermediary server, MQTT Broker, is an intermediary server that enables communication between the device and the bridging group. Specifically, the MQTT Broker receives messages published by the device, filters them according to topics, and distributes them to subscribers. In this embodiment, during the process of the device sending messages to the platform, the bridging service in the bridging group can be a subscriber.

[0082] Furthermore, the second intermediary server, MQ Broker, also known as message queue middleware, is an important component in distributed systems. It mainly solves problems such as application decoupling, asynchronous messaging, and traffic shaping, and achieves a high-performance, highly available, scalable, and eventually consistent architecture.

[0083] Furthermore, each MQ Broker and each MQTT Broker can be a server cluster or processor cluster consisting of multiple servers or processors, or it can be a single server or processor.

[0084] In this embodiment, as Figure 1 As shown, based on the architecture of the cloud platform already shown, more bridging groups, cloud services, first intermediary servers, and second intermediary servers can be added.

[0085] Furthermore, Figure 1 The cloud platform shown connects to multiple external devices through an internally configured load balancing service, and the number of devices connected to the cloud platform can be expanded according to specific needs.

[0086] In some other embodiments, the load balancing service may be removed depending on the specific circumstances.

[0087] In the specific implementation scenario of this embodiment, the device can be an IoT device, the cloud platform can be an IoT cloud platform, and the cloud services in the cloud platform can be IoT services. Based on this, the device and the cloud platform form an information exchange about IoT services.

[0088] exist Figure 1 In the specific example shown, the process of sending messages or instructions from the device to the cloud platform is considered the message uplink process, i.e. Figure 2 The diagram illustrates the message routing for uplink messages; while the process of sending messages or instructions from the cloud platform to the device is the downlink message routing process, i.e. Figure 3 The message route shown is the message route for the downstream message.

[0089] refer to Figure 4 One embodiment of this application provides a method for accessing a physical device, comprising the following steps:

[0090] Step S401: Establish a connection between the at least one bridging group and a preset corresponding physical device.

[0091] In the embodiments of this application, the bridging group in the cloud platform connects to various devices outside the cloud platform on one side and to various cloud services in the cloud platform on the other side, so as to bridge the various devices and various cloud services.

[0092] Multiple bridging groups can be set up in the cloud platform, and each bridging group can be connected to at least one device outside the cloud platform.

[0093] Specifically, a first intermediary server can be set up for each bridging group, meaning that there is a unique correspondence between each bridging group and its corresponding first intermediary server.

[0094] Furthermore, each first intermediary server is connected to each bridge service in its corresponding bridge group.

[0095] Furthermore, each first intermediary server connects to at least one device outside the remote platform.

[0096] It can be determined that each bridging group can connect to at least one device through the corresponding first intermediary server.

[0097] exist Figure 1 In the specific example shown, taking bridging group 1 as an example, it can be seen that a first intermediary server MQTT Broker1 is set up between bridging group 1 and the device.

[0098] Furthermore, MQTT Broker1 is connected to the two bridging services MQTT-MQ-Bridge11-1 and MQTT-MQ-Bridge11-2 in bridging group 1, respectively.

[0099] Furthermore, MQTT Broker1 connects to at least one of multiple devices outside the cloud platform through a configured load balancing service.

[0100] Based on this, a bridging group can be connected to at least one device outside the cloud platform. Specifically, the bridging service in the bridging group connects to at least one device through an intermediary server. Based on the set first intermediary server, multiple devices can be connected to the corresponding bridging group.

[0101] In some other embodiments, multiple bridging groups may share a single first intermediary server.

[0102] Step S402: In response to receiving at least one device message from any physical device, obtain different device messages through each bridging service in the bridging group corresponding to each physical device, and report them to any cloud service.

[0103] In the embodiments of this application, during the message uplink process, after the device sends a device message to the cloud platform, the cloud platform can receive the device message through the load balancing service, and the device message can be obtained by each bridging service in the corresponding bridging group.

[0104] The device message can be one or more device messages sent by one or more devices. When the bridging group obtains the device message, each bridging service in the bridging group can obtain different device messages. This avoids two different bridging services receiving the same device message and performing the same processing, thereby avoiding waste of resources.

[0105] It should be noted that in this embodiment, the multiple devices that send multiple device messages can correspond to different bridging groups. In other words, through the corresponding connection relationship described in the foregoing embodiment, each bridging group of the cloud platform can obtain the device messages of the corresponding devices.

[0106] In other embodiments, when a first intermediary server is set up in the cloud platform, the first intermediary server can receive the device messages sent by the corresponding device through the load balancing service, publish them to the bridging group, and then each bridging service in the bridging group can obtain the device messages by subscription.

[0107] Specifically, based on the foregoing embodiments, each bridging group is connected to a first intermediary server, and each bridging service in the bridging group can execute a publish-subscribe messaging paradigm with the corresponding first intermediary server.

[0108] Therefore, each bridging service in the bridging group can subscribe to device messages published by the corresponding first intermediary server using the same group name.

[0109] Based on this, after the device message is published by the first intermediary server, each corresponding bridging service can obtain different device messages, thus avoiding the duplicate processing of the same device message.

[0110] Furthermore, after obtaining device messages, each bridging service can report them to any cloud service, and each cloud service can receive multiple reported device messages separately.

[0111] The device messages reported to the cloud service can be one or more device messages published by one or more bridging groups. When publishing multiple device messages to the cloud service, each cloud service can obtain different device messages, thereby avoiding two different cloud services receiving the same device messages and performing the same processing, thus avoiding waste of resources.

[0112] In other embodiments, when a second intermediary server is set up in the cloud platform, the second intermediary server can receive device messages sent by the corresponding bridging group and publish them to various cloud services, which can then obtain the device messages by subscription.

[0113] Specifically, based on the foregoing embodiments, each cloud service is connected to multiple second intermediary servers, and each cloud service and each connected second intermediary server can execute a publish-subscribe messaging paradigm.

[0114] Therefore, various cloud services can subscribe to device messages published by various secondary intermediary servers using the same group name.

[0115] Based on this, after the device message is published by the second intermediary server, each cloud service that has subscribed to the device message can obtain different device messages and process them, thus avoiding the duplicate processing of the same device message.

[0116] As can be seen, based on the multiple bridging groups and the multiple bridging services in each bridging group, each bridging service in each bridging group can subscribe to different device messages. Furthermore, during message uplink, the first intermediary server, based on the characteristics of the first intermediary server in the aforementioned embodiment, can expand the number of devices connected to the cloud platform and group and publish a large number of device messages sent by multiple connected devices to multiple bridging groups, thereby increasing the number of connected devices and the throughput of device messages during message uplink. In addition, during the process of sending device messages to cloud services, the publish-subscribe pattern executed by the second intermediary server allows each cloud service to process different device messages. Moreover, when multiple first intermediary servers are set up, even if a device connects to another first intermediary server due to unforeseen reasons, the uplink message routing can still be performed correctly. Based on the characteristics of the second intermediary server in the aforementioned embodiment, the number of device messages connected to the cloud platform can be expanded, increasing the throughput of device messages.

[0117] In some other embodiments of this application, in Figure 1 In the specific example shown, taking the bridging service MQTT-MQ-Bridge11-1 in bridging group 1 as an example, after the bridging service MQTT-MQ-Bridge11-1 starts, it will read and record the address and name of the MQTT Broker and MQ Broker it connects to, and read the name and group name of MQTT-MQ-Bridge11-1 itself.

[0118] The MQTT Broker connected to MQTT-MQ-Bridge11-1 is named MQTT Broker1, the MQBroker is named MQ Broker1, and the group name of MQTT-MQ-Bridge11-1 is Group1.

[0119] Furthermore, after startup, MQTT-MQ-Bridge11-1 can also read the unique device tag $SN of each device connected to bridge group 1.

[0120] Furthermore, MQTT-MQ-Bridge11-1 will create a receiving and sending unit for receiving and sending messages and commands, and will call it a Client. Figure 1 In the example, MQTT-MQ-Bridge11-1 will create two clients: MQTT Client and MQ Client.

[0121] The MQTT Client is used to receive and send messages and commands with the MQTT Broker1. Therefore, a corresponding MQTT Client receiving and sending unit is pre-created in the MQTT Broker1 and can be named MQTTClientx.

[0122] Furthermore, the MQ Client is used to receive and send messages and commands with the MQ Broker1. Therefore, a corresponding MQ Client receiving and sending unit is pre-created in the MQ Broker1, which can be named MQ Clientx.

[0123] Furthermore, MQTT-MQ-Bridge11-1 can subscribe to the system topics of MQTT Broker1 through the MQTT Client. For example, when MQTT-MQ-Bridge11-1 receives the statement: $event / client_connected from MQTT Broker1, it initiates the subscription to the system topics of MQTT Broker1. In some embodiments, it can also be regarded as establishing a connection between MQTT-MQ-Bridge11-1 and MQTT Broker1 through the statement: $event / client_connected.

[0124] Based on this, after MQTT-MQ-Bridge11-1 subscribes to the system topic of MQTT Broker1, MQTT-MQ-Bridge11-1 will use the names of MQTT Broker1 and MQ Broker1, as well as the device labels $SN, read above, to determine the mapping relationship between the bridge group and the corresponding first intermediary server, the corresponding second intermediary server, and the corresponding device. That is, the mapping relationship between Group1 and MQTT Broker1, MQ Broker1 and device labels $SN, and cache this mapping relationship in the cache database of the cloud platform.

[0125] In this embodiment, the two bridging services MQTT-MQ-Bridge11-1 and MQTT-MQ-Bridge11-2 in bridging group 1 act as subscribers and both use the same group name: Group1 to subscribe to device messages from MQTT Broker1.

[0126] Based on this, the MQTT Client in MQTT-MQ-Bridge11-1 can receive device messages published by the MQTT Broker and forward them to the MQ Broker.

[0127] Specifically, after MQTT Broker1 publishes multiple device messages, such as msg1, msg2, and msg3, the two subscribers MQTT-MQ-Bridge11-1 and MQTT-MQ-Bridge11-2 each receive different device messages. For example, MQTT-MQ-Bridge11-1 receives msg1, while MQTT-MQ-Bridge11-2 receives msg2 and msg3.

[0128] To ensure subscribers receive the device messages they have subscribed to, MQTT Broker1 can add fixed statements to the message payload of the device messages it publishes, such as iot / report / #. Here, iot indicates that the message is sent to the cloud service, and report indicates that the message in this device message needs to be reported to the cloud service.

[0129] Furthermore, when MQTT-MQ-Bridge11-1 receives the statement $event / client_disconnected from MQTT Broker1, it can unsubscribe from the MQTT Broker1 system topic, that is, cancel the connection between MQTT-MQ-Bridge11-1 and MQTT Broker1.

[0130] Furthermore, after obtaining the device message, MQTT-MQ-Bridge11-1 can send the device message to MQ Broker through MQClient. MQ Clientx in MQ Broker will then receive the device message and publish it to IoT Service 1, IoT Service 2, and IoT Service 3.

[0131] Furthermore, each of IoT Service 1, IoT Service 2, and IoT Service 3 has a pre-built transceiver unit for connecting to each MQBroker. That is, in IoT Service 1, IoT Service 2, and IoT Service 3, there is an MQ Client x1 corresponding to MQBroker 1 and an MQ Client x2 corresponding to MQ Broker 2.

[0132] Based on this, IoT service 1, IoT service 2, and IoT service 3 can use the same group name to subscribe to device messages published by MQ Broker1 and MQ Broker2. In other words, IoT service 1, IoT service 2, and IoT service 3 are treated as three subscribers in the same group to subscribe to device messages from two publishers, MQ Broker1 and MQ Broker2. Therefore, the device messages obtained by each of IoT service 1, IoT service 2, and IoT service 3 are different.

[0133] Step S403: In response to receiving at least one device message from any physical device, obtain different device messages through each bridging service in the bridging group corresponding to each physical device, and report them to any cloud service.

[0134] In the embodiments of this application, during the message downlink process, the cloud platform sends service instructions to the device, and can send the service instructions to the corresponding device through each bridging group.

[0135] The service instructions are sent to a pre-specified device. Therefore, each service instruction includes the device tag of the specified device. The service instructions can be one or more service instructions issued by one or more cloud services, and the service instructions are sent to the corresponding device through a bridge group connected to the corresponding device.

[0136] Specifically, after each cloud service starts and generates a service instruction, based on the mapping relationship cached in the aforementioned embodiments, the mapping relationship can be retrieved from the cache database, and the second intermediary server, bridging group, and first intermediary server corresponding to each device tag can be determined.

[0137] Based on the obtained mapping relationship, the cloud service can determine the corresponding first intermediary server according to the device tag, add the unique first intermediary tag of the first intermediary server to the service instruction, and use the service instruction with the added first intermediary tag as the tag instruction.

[0138] Furthermore, the label instruction is sent to the second intermediary server corresponding to the first intermediary label.

[0139] Furthermore, after the second intermediary server receives the service instruction, it publishes the tag instruction to the bridging group corresponding to the first intermediary tag, and a bridging service in the bridging group receives the tag instruction.

[0140] In this embodiment, when the second intermediary server publishes tag instructions to the bridging group, based on the publish-subscribe message paradigm between each bridging service and the second intermediary server, each bridging service uses the same group name and subscribes to the tag instructions published by the second intermediary server as multiple subscribers within the same group.

[0141] Therefore, when the second intermediary server issues multiple tag instructions, each bridging service in the bridging group can obtain different tag instructions, thereby avoiding two different bridging services receiving the same tag instructions and performing the same processing, thus avoiding waste of resources.

[0142] Furthermore, after the bridging service obtains the label instruction, it will remove the first intermediary label from the label instruction to obtain the aforementioned service instruction, and send the service instruction to the corresponding first intermediary server.

[0143] Furthermore, after receiving the service instruction, the first intermediary server can send the service instruction to the corresponding device.

[0144] In some other embodiments of this application, in Figure 1 In the specific example shown, taking cloud service IoT service 1 as an example, when IoT service 1 is started and generates a service instruction, the service instruction contains the device tag $SN of the device.

[0145] Furthermore, based on the mapping relationship determined in the foregoing embodiments, IoT service 1 can determine the first intermediary server to which the device is connected based on the device tag $SN, for example, it could be MQTT Broker 1.

[0146] Based on this, IoT service 1 can use the name "MQTT Broker1" as the first intermediary label and append it as a prefix to the service instruction to obtain the corresponding label instruction.

[0147] Furthermore, IoT service 1 can also identify the MQ Broker 1 that is connected to MQTT Broker 1.

[0148] Based on this, IoT service 1 can use MQ Clientx1 to publish tag commands to MQ Broker 1.

[0149] Furthermore, after MQ Broker1 receives the tag instruction, it can publish the tag instruction to the corresponding bridge group 1 according to the first intermediary tag: MQTTBroker1.

[0150] Furthermore, the two bridging services MQTT-MQ-Bridge11-1 and MQTT-MQ-Bridge11-2 in bridging group 1, as two subscribers, both use the same group name: Group1 to subscribe to the MQ Broker's tag instructions.

[0151] Based on this, the MQ Client in MQTT-MQ-Bridge11-1 can receive device messages published by the MQ Broker and forward them to the corresponding MQTT Broker.

[0152] Specifically, after MQ Broker1 publishes multiple tag instructions, the two subscribers MQTT-MQ-Bridge11-1 and MQTT-MQ-Bridge11-2 each receive different tag instructions.

[0153] Furthermore, taking MQTT-MQ-Bridge11-1 as an example, after receiving the tag instruction, since MQTT-MQ-Bridge11-1 is only connected to the first intermediary server MQTT Broker1, the first intermediary tag "MQTT Broker1" in the tag instruction can be removed, and the service instruction can be obtained.

[0154] Furthermore, MQTT-MQ-Bridge11-1 can use MQTT Client to send service commands to the corresponding MQTT Broker, and MQTT Broker1 can use MQTT Clientx to receive the service commands.

[0155] Furthermore, MQTT Broker1 can send the received service commands to the corresponding connected devices outside the cloud platform.

[0156] As can be seen, based on the multiple bridging groups and the multiple bridging services in each bridging group, each bridging service in each bridging group can subscribe to different service instructions. Furthermore, during message downlink, the routing line corresponding to the service instruction generated by the cloud service is determined through the mapping relationship between the first intermediary server, the second intermediary server, the bridging group, and the device. When multiple first intermediary servers are set up, even if the device connects to another first intermediary server due to unforeseen reasons, the downlink message routing can still be performed correctly. Based on the characteristics of the second intermediary server in the aforementioned embodiment, the second intermediary server can obtain a large number of service instructions from a large number of different cloud services and process them effectively, that is, effectively publish them to the corresponding bridging groups. Based on this, the number of service instructions published by the cloud platform is increased, and the throughput of service instructions is improved.

[0157] In some other embodiments of this application, the physical device may include a plurality of second physical devices, each of which may run at least one first application.

[0158] The second physical device can interact with the cloud platform through the first application. The first application can send device messages of the second physical device to the cloud platform and receive service instructions from the cloud platform.

[0159] Specifically, the cloud platform can connect to the second physical device according to the physical device access method described in any of the above embodiments, and access the device messages of the first application according to the physical device access method described in any of the above embodiments.

[0160] Furthermore, the cloud platform can receive and process service instructions sent by the first application according to the access method of the physical device described in any of the above embodiments.

[0161] In this embodiment, the physical device can be a conference all-in-one machine, the first physical device can be a communication module or central processing unit installed in the conference all-in-one machine, and the first application can be an online conferencing application installed in the communication module or central processing unit.

[0162] Furthermore, the cloud platform can be the backend of an online conferencing application and consists of multiple servers and / or databases.

[0163] Based on this, the backend of the online conferencing application can access one or more conferencing all-in-one machines and connect to hardware such as the communication module or central processing unit therein, according to the physical device access method described in any of the above embodiments.

[0164] Furthermore, the backend of the online conferencing application can receive device messages sent by the online conferencing application and send service instructions to the online conferencing application in accordance with the physical device access method described in any of the above embodiments.

[0165] In this embodiment, the physical device can be a home appliance such as a television, air conditioner, and curtains. The first physical device can be hardware such as a communication module or central processing unit installed in the home appliance such as a television, air conditioner, and curtains. The first application can be a smart home appliance control application installed in the communication module or central processing unit.

[0166] Furthermore, the cloud platform can be the backend for smart home appliance control applications and consists of multiple servers and / or databases.

[0167] Based on this, the backend of the smart home appliance control application can access one or more home appliances such as televisions, air conditioners, and curtains by following the physical device access method described in any of the above embodiments, and connect with hardware such as communication modules or central processing units therein.

[0168] Furthermore, the backend of the smart home appliance control application can receive device messages sent by the smart home appliance control application and send service instructions to the smart home appliance control application in accordance with the physical device access method described in any of the above embodiments.

[0169] As can be seen, the physical device access method of the embodiments of this application, based on multiple bridge groups and multiple bridge services set in each bridge group, not only considers the need to handle a large number of device accesses and a large number of message accesses simultaneously when devices access the cloud platform, but also considers the need for the cloud platform's cloud services to handle a large number of message accesses without simultaneously handling a large number of device accesses when interacting with device messages and service commands. Based on the comprehensive consideration of the above two points, multiple first intermediary servers and multiple second intermediary servers are set up. When each first intermediary server and each second intermediary service interacts with multiple bridge services, the publish-subscribe messaging paradigm is used so that each bridge service can obtain different device messages and service commands, maximizing the utilization of the computing power of each bridge service, thereby enabling a large number of devices to access the cloud platform and improving the message throughput of the cloud platform.

[0170] It should be noted that the method of the embodiments of this application can be executed by a single device, such as a computer or server. The method of this embodiment can also be applied in a distributed scenario, where multiple devices cooperate to complete the task. In such a distributed scenario, one of these devices may execute only one or more steps of the method of the embodiments of this application, and the multiple devices will interact with each other to complete the method described.

[0171] It should be noted that the above description describes some embodiments of this application. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in a different order than that shown in the above embodiments and still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0172] Based on the same inventive concept, corresponding to the methods of any of the above embodiments, the embodiments of this application also provide an access device for a physical device, wherein the cloud platform includes multiple bridging groups and multiple cloud services, and each bridging group includes at least one bridging service.

[0173] refer to Figure 5 The access device for the physical device includes: a connection module 501, an uplink module 502, and a downlink module 503;

[0174] The connection module 501 is configured to enable at least one bridging group to establish a connection with a preset corresponding physical device.

[0175] The uplink module 502 is configured to, in response to receiving at least one device message from any physical device, obtain different device messages through each bridging service in the bridging group corresponding to each physical device, and report them to any cloud service.

[0176] The downlink module 503 is configured to, in response to any cloud service generating at least one service instruction, determine the physical device to which each service instruction points, send each service instruction to the bridge group connected to the physical device to which it points, and cause each bridge service in each bridge group receiving the service instruction to obtain different service instructions and forward them to the physical device to which it is connected.

[0177] As an optional embodiment, the cloud platform also includes multiple first intermediary servers, and the connection module 501 is specifically configured as follows:

[0178] Connect a first intermediary server to each bridging group, and connect the first intermediary server to all physical devices corresponding to the bridging group.

[0179] Each first intermediary server connects to each bridge service in the corresponding bridge group.

[0180] Furthermore, the cloud platform also includes load balancing services;

[0181] Establishing a connection between the at least one bridging group and a preset corresponding physical device further includes:

[0182] The load balancing service is connected to all physical devices outside the cloud platform and to all first intermediary servers;

[0183] The load balancing service receives device messages from each physical device and sends the received device messages to the corresponding first intermediary server.

[0184] The load balancing service receives service instructions from each of the first intermediary servers and sends the received service instructions to the corresponding physical devices.

[0185] As an optional embodiment, the cloud platform also includes multiple second intermediary servers, and the uplink module 502 is specifically configured as follows:

[0186] The first intermediary server receives at least one device message from the corresponding physical device and publishes the at least one device message to the corresponding bridging group.

[0187] Each bridging service in the corresponding bridging group shall obtain device messages from the first intermediary server using a publish-subscribe messaging paradigm.

[0188] Specifically, each bridging service in the corresponding bridging group acquires device messages from the first intermediary server using a publish-subscribe messaging paradigm, including:

[0189] Set the same bridge group name for each bridge service in the same bridge group;

[0190] In response to each bridging service in the same bridging group subscribing to various device messages published by the first intermediary server using the same bridging group name, each bridging service receives different device messages.

[0191] Furthermore, the at least one bridging group is connected to the same second intermediary server, and each second intermediary server is connected to various cloud services;

[0192] Each bridging service sends its respective device message to the second intermediary server for the corresponding connection;

[0193] Set the same service group name for each cloud service;

[0194] In response to each second intermediary server publishing device messages to each cloud service, and each cloud service subscribing to each device message using the same service group name, each cloud service receives different device messages.

[0195] The process of connecting at least one bridging group to the same second intermediary server further includes:

[0196] Each bridging group stores and maintains the mapping relationships between itself and the corresponding first intermediary server, the corresponding second intermediary servers, and the corresponding physical devices.

[0197] The mapping relationship is then stored in each cloud service.

[0198] As an optional embodiment, the service instruction includes the device tag of the corresponding device, and the downlink module 503 is specifically configured as follows:

[0199] The cloud service is instructed to determine the second intermediary server and the corresponding first intermediary server corresponding to the device tag according to the mapping relationship;

[0200] The cloud service adds the first intermediary tag of the corresponding first intermediary server to the service instruction to obtain the tag instruction, and sends it to the corresponding second intermediary server.

[0201] The second intermediary server is instructed to issue the tag instruction to the corresponding bridging service group according to the first intermediary tag.

[0202] Furthermore, in response to each bridging service in the same bridging group subscribing to the tag instruction published by the second intermediary server using the same bridging group name, each bridging service receives a different tag instruction.

[0203] Remove the first intermediary tag added in the tag instruction from each bridging service to obtain the service instruction.

[0204] Further, the service instruction is sent to the first intermediary server corresponding to the first intermediary tag;

[0205] The corresponding first intermediary server is instructed to send the service instruction to the physical device connected to the first intermediary server according to the device tag.

[0206] For ease of description, the above apparatus is described in terms of its functions, divided into various modules. Of course, in implementing the embodiments of this application, the functions of each module can be implemented in one or more software and / or hardware.

[0207] The apparatus described above is used to implement the access method of the corresponding physical device in any of the foregoing embodiments, and has the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0208] Based on the same inventive concept, corresponding to the methods of any of the above embodiments, embodiments of this application also provide a resource integration system, which includes at least one physical device and at least one access device for the physical device as described in any of the above embodiments, wherein each physical device is connected to the access device.

[0209] In response to the at least one physical device sending at least one device message to the access device, the access device is instructed to execute the physical device access method as described in any of the above embodiments to access each physical device and receive each device message;

[0210] In response to the access device executing the physical device access method as described in any of the above embodiments, at least one service instruction is sent to at least one physical device, causing each physical device to receive the corresponding service instruction.

[0211] The system of the above embodiments is configured to implement the access method of the corresponding physical device in any of the foregoing embodiments, and has the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0212] Based on the same inventive concept, corresponding to the methods of any of the above embodiments, the embodiments of this application also provide an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the physical device access method as described in any of the above embodiments.

[0213] Figure 6 This embodiment illustrates a more specific hardware structure of an electronic device, which may include a processor 1010, a memory 1020, an input / output interface 1030, a communication interface 1040, and a bus 1050. The processor 1010, memory 1020, input / output interface 1030, and communication interface 1040 are interconnected internally via the bus 1050.

[0214] The processor 1010 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application.

[0215] The memory 1020 can be implemented in the form of ROM (Read Only Memory), RAM (Random Access Memory), static storage device, dynamic storage device, etc. The memory 1020 can store the operating system and other applications. When the technical solutions provided in the embodiments of this application are implemented by software or firmware, the relevant program code is stored in the memory 1020 and is called and executed by the processor 1010.

[0216] The input / output interface 1030 is used to connect input / output modules to realize information input and output. Input / output modules can be configured as components within the device (not shown in the figure) or externally connected to the device to provide corresponding functions. Input devices may include keyboards, mice, touchscreens, microphones, various sensors, etc., while output devices may include displays, speakers, vibrators, indicator lights, etc.

[0217] The communication interface 1040 is used to connect a communication module (not shown in the figure) to enable communication between this device and other devices. The communication module can communicate via wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.).

[0218] Bus 1050 includes a pathway for transmitting information between various components of the device, such as processor 1010, memory 1020, input / output interface 1030, and communication interface 1040.

[0219] It should be noted that although the above-described device only shows the processor 1010, memory 1020, input / output interface 1030, communication interface 1040, and bus 1050, in specific implementations, the device may also include other components necessary for normal operation. Furthermore, those skilled in the art will understand that the above-described device may only include the components necessary for implementing the embodiments of this application, and not necessarily all the components shown in the figures.

[0220] The apparatus described above is used to implement the access method of the corresponding physical device in any of the foregoing embodiments, and has the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0221] Based on the same inventive concept, corresponding to the methods of any of the above embodiments, this application also provides a non-transitory computer-readable storage medium that stores computer instructions for causing the computer to execute the physical device access method as described in any of the above embodiments.

[0222] The computer-readable medium of this embodiment includes permanent and non-permanent, removable and non-removable media, and information storage can be implemented by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device.

[0223] The computer instructions stored in the storage medium of the above embodiments are used to cause the computer to execute the physical device access method as described in any of the above embodiments, and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0224] Those skilled in the art should understand that the discussion of any of the above embodiments is merely exemplary and is not intended to imply that the scope of this application (including the claims) is limited to these examples; within the framework of this application, the technical features of the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other variations of different aspects of the embodiments of this application as described above, which are not provided in detail for the sake of brevity.

[0225] Additionally, to simplify the description and discussion, and to avoid obscuring the embodiments of this application, the well-known power / ground connections to integrated circuit (IC) chips and other components may or may not be shown in the provided drawings. Furthermore, the apparatus may be shown in block diagram form to avoid obscuring the embodiments of this application, and this also takes into account the fact that the details of implementation of these block diagram apparatuses are highly dependent on the platform on which the embodiments of this application will be implemented (i.e., these details should be fully understood by those skilled in the art). While specific details (e.g., circuits) have been set forth to describe exemplary embodiments of this application, it will be apparent to those skilled in the art that the embodiments of this application can be implemented without these specific details or with variations thereof. Therefore, these descriptions should be considered illustrative rather than restrictive.

[0226] Although this application has been described in conjunction with specific embodiments thereof, many substitutions, modifications, and variations of these embodiments will be apparent to those skilled in the art from the foregoing description. For example, other memory architectures (e.g., dynamic RAM (DRAM)) may be used with the embodiments discussed.

[0227] The embodiments of this application are intended to cover all such substitutions, modifications, and variations that fall within the broad scope of the appended claims. Therefore, any omissions, modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the embodiments of this application should be included within the protection scope of this application.

Claims

1. A method for connecting a physical device, characterized in that, The method is applied to a cloud platform, which includes at least one bridging group, multiple cloud services, multiple first intermediary servers, and multiple second intermediary servers; each bridging group includes at least one bridging service; the first intermediary server is an intermediary server that enables communication between the bridging group and the corresponding physical device. The second intermediary server connects to each cloud service. The second intermediary server is used to receive device messages sent by the corresponding bridging group and publish them to each cloud service. The method includes: The at least one bridging group establishes a connection with a preset corresponding physical device; In response to receiving at least one device message from any physical device, the system obtains different device messages through each bridging service in the bridging group corresponding to each physical device and reports them to any cloud service. In response to any cloud service generating at least one service instruction, the physical device to which each service instruction points is determined, and each service instruction is sent to the bridge group connected to the physical device to which it points, so that each bridge service in each bridge group receiving the service instruction obtains a different service instruction and forwards it to the physical device to which it is connected. The reporting to any cloud service includes: The at least one bridging group is connected to the same second intermediary server, and each second intermediary server is connected to various cloud services; Each bridging service sends its respective device message to the second intermediary server for the corresponding connection; Set the same service group name for each cloud service; In response to each second intermediary server publishing device messages to each cloud service, and each cloud service subscribing to each device message using the same service group name, each cloud service receives different device messages.

2. The method according to claim 1, characterized in that, The step of establishing a connection between the at least one bridging group and a preset corresponding physical device includes: Connect a first intermediary server to each bridging group, and connect the first intermediary server to all physical devices corresponding to the bridging group. Each first intermediary server connects to each bridge service in the corresponding bridge group.

3. The method according to claim 2, characterized in that, The step of obtaining different device messages through each bridging service in the bridging group corresponding to each of the arbitrary physical devices includes: The first intermediary server receives at least one device message from the corresponding physical device and publishes the at least one device message to the corresponding bridging group. Each bridging service in the corresponding bridging group shall obtain device messages from the first intermediary server using a publish-subscribe messaging paradigm.

4. The method according to claim 3, characterized in that, The step of having each bridging service in the corresponding bridging group obtain device messages from the first intermediary server using a publish-subscribe messaging paradigm includes: Set the same bridge group name for each bridge service in the same bridge group; In response to each bridging service in the same bridging group subscribing to various device messages published by the first intermediary server using the same bridging group name, each bridging service receives different device messages.

5. The method according to claim 4, characterized in that, After connecting the at least one bridging group to the same second intermediary server, the method further includes: Each bridging group stores and maintains the mapping relationships between itself and the corresponding first intermediary server, the corresponding second intermediary servers, and the corresponding physical devices. The mapping relationship is then stored in each cloud service.

6. The method according to claim 5, characterized in that, The service instruction includes the device tag of the physical device to which it is directed; The step of sending each service instruction to the bridge group connected to its respective physical device includes: The cloud service is instructed to determine the second intermediary server and the corresponding first intermediary server corresponding to the device tag according to the mapping relationship; The cloud service adds the first intermediary tag of the corresponding first intermediary server to the service instruction to obtain the tag instruction, and sends it to the corresponding second intermediary server. The second intermediary server is instructed to issue the tag instruction to the corresponding bridging service group according to the first intermediary tag.

7. The method according to claim 6, characterized in that, The step of having each bridge service in each bridge group receiving service instructions obtain different service instructions, including: In response to each bridging service in the same bridging group subscribing to the tag instruction published by the second intermediary server using the same bridging group name, each bridging service receives a different tag instruction. Remove the first intermediary tag added in the tag instruction from each bridging service to obtain the service instruction.

8. The method according to claim 6, characterized in that, The forwarding to their respective connected physical devices includes: The service instruction is sent to the first intermediary server corresponding to the first intermediary tag; The corresponding first intermediary server is instructed to send the service instruction to the physical device connected to the first intermediary server according to the device tag.

9. The method according to claim 2, characterized in that, The cloud platform also includes load balancing services; The step of establishing a connection between the at least one bridging group and a preset corresponding physical device further includes: The load balancing service is connected to all physical devices outside the cloud platform and to all first intermediary servers; The load balancing service receives device messages from each physical device and sends the received device messages to the corresponding first intermediary server. The load balancing service receives service instructions from each of the first intermediary servers and sends the received service instructions to the corresponding physical devices.

10. The method according to any one of claims 1-9, characterized in that, The at least one physical device includes at least one second physical device, and the second physical device runs at least one first application; The cloud platform connects to each of the second physical devices according to the physical device access method as described in any one of claims 1-9, receives device messages from each first application, and sends service instructions to the corresponding first application.

11. A device for accessing a physical device, characterized in that, include: Connection module, uplink module, and downlink module; The connection module is configured to enable at least one bridging group to establish a connection with a preset corresponding physical device. The uplink module is configured to, in response to receiving at least one device message from any physical device, obtain different device messages through each bridging service in the bridging group corresponding to each physical device, and report them to any cloud service. The downlink module is configured to, in response to any cloud service generating at least one service instruction, determine the physical device to which each service instruction points, send each service instruction to the bridge group connected to the physical device to which it points, and cause each bridge service in each bridge group receiving the service instruction to obtain different service instructions and forward them to the physical device to which it is connected. The uplink module is specifically configured to: connect the at least one bridging group to the same second intermediary server, and connect each second intermediary server to various cloud services; Each bridging service sends its respective device message to the second intermediary server for the corresponding connection; Set the same service group name for each cloud service; In response to each second intermediary server publishing device messages to each cloud service, and each cloud service subscribing to each device message using the same service group name, each cloud service receives different device messages.

12. A resource integration system, characterized in that, The system includes at least one physical device and at least one access device for the physical device as described in claim 11, wherein each physical device is connected to the access device. In response to the at least one physical device sending at least one device message to the access device, the access device is instructed to execute the physical device access method according to any one of claims 1 to 9 to access each physical device and receive each device message; In response to the access device performing the access method for physical devices according to any one of claims 1 to 9, at least one service instruction is sent to at least one physical device, causing each physical device to receive the corresponding service instruction.

13. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable by the processor, characterized in that, When the processor executes the computer program, it implements the method as described in any one of claims 1 to 9.

14. A non-transitory computer-readable storage medium, characterized in that, The non-transitory computer-readable storage medium stores computer instructions for causing the computer to perform the method according to any one of claims 1 to 9.

Images