Device collaborative processing method, device, edge gateway, system and storage medium

Abstract

The present invention relates to the field of edge computing technology, and the present invention discloses a device collaborative processing method, apparatus, edge gateway, system and storage medium. The method receives a task to be processed sent by a first device, adopts a target collaborative microservice corresponding to the task type, and collaboratively processes the first data in the task to be processed according to the task type in the task to be processed, thereby obtaining the processed and converted second data. By adopting the target collaborative microservice to process the first data, the dependence on the third-party API or SDK is reduced; if the task to be processed includes a second device identifier, the second data is sent to the second device corresponding to the second device identifier; if the task to be processed does not include the second device identifier, the second data is stored in a local memory, so that the second data processed by the target collaborative microservice is forwarded according to the task to be processed, so as to improve the stability of the connection between the first device, the second device and the edge gateway.

Description

Technical Field

[0001] The present invention relates to the field of edge computing technology, and in particular to a device collaborative processing method, device, edge gateway, system and storage medium. Background Art

[0002] Edge computing, also known as distributed computing, allows computer data to be stored closer to where it's needed, compared to relying solely on cloud computing. This distributed data processing approach significantly reduces the demand on equipment for data transmission and processing capabilities. The most typical application model involves collecting production-side information through various monitoring and sensor devices, aggregating this information and sending it to an edge gateway. High-performance processors pre-process the data for analysis, screening, and judgment, and then transmit the dense data to an industrial cloud platform via network ports. This enables timely and efficient reporting of production information, meeting managers' monitoring and decision-making needs.

[0003] Currently, due to the different protocols used by various devices, IoT devices rely on third-party device APIs or SDKs to connect to edge gateways and connected cloud platforms. The device then interacts with the cloud platform through interfaces encapsulated by the APIs or SDKs. Third-party implementations of device access logic increase device access costs, while reliance on third parties increases the risks associated with connecting IoT cloud platforms and IoT devices, reducing the stability of edge computing. Existing device access solutions are highly dependent on third parties, leading to lower edge computing stability. Summary of the Invention

[0004] Embodiments of the present invention provide a device collaborative processing method, apparatus, edge gateway, system and storage medium to solve the problem of low stability in edge computing in the prior art.

[0005] An embodiment of the present invention provides a device collaborative processing method, including:

[0006] receiving a to-be-processed task sent by a first device, where the to-be-processed task includes a task type and first data;

[0007] Using the target collaborative microservice corresponding to the task type to collaboratively process the first data to obtain second data;

[0008] If the task to be processed includes a second device identifier, sending the second data to a second device corresponding to the second device identifier;

[0009] If the task to be processed does not include the second device identifier, the second data is stored in the local memory.

[0010] An embodiment of the present invention further provides a device coordination apparatus, including:

[0011] a pending task receiving module, configured to receive a pending task sent by a first device, wherein the pending task includes a task type and first data;

[0012] A second data acquisition module is configured to collaboratively process the first data using a target collaborative microservice corresponding to the task type to acquire second data;

[0013] a second data sending module, configured to send the second data to a second device corresponding to the second device identifier if the task to be processed includes a second device identifier;

[0014] The second data storage module is configured to store the second data in a local memory if the task to be processed does not include a second device identifier.

[0015] An embodiment of the present invention further provides an edge gateway, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the above-mentioned device collaborative processing method when executing the computer program.

[0016] An embodiment of the present invention also provides an Internet of Things system, including the above-mentioned edge gateway, and also including an Internet of Things cloud platform and an Internet of Things device that communicate with the edge gateway; the Internet of Things cloud platform is the first device, and the Internet of Things device is the second device; or, the Internet of Things device or the edge gateway is the first device, and the Internet of Things cloud platform is the second device.

[0017] An embodiment of the present invention further provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the device collaborative processing method described above is implemented.

[0018] The above-mentioned device collaborative processing method, apparatus, edge gateway, system and storage medium receive the task to be processed sent by the first device, adopt the target collaborative microservice corresponding to the task type, and collaboratively process the first data in the task to be processed according to the task type in the task to be processed, thereby obtaining the processed and converted second data. By adopting the target collaborative microservice to process the first data, the dependence on the third-party API or SDK is reduced; if the task to be processed includes the second device identifier, the second data is sent to the second device corresponding to the second device identifier; if the task to be processed does not include the second device identifier, the second data is stored in the local memory, so that the second data processed by the target collaborative microservice is forwarded according to the task to be processed, so as to improve the stability of the connection between the first device, the second device and the edge gateway. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments of the present invention. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0020] Figure 1 This is a schematic diagram of an application environment of a device collaborative processing method according to an embodiment of the present invention;

[0021] Figure 2 is a flow chart of a device collaborative processing method according to an embodiment of the present invention;

[0022] Figure 3 is another flow chart of a device collaborative processing method according to an embodiment of the present invention;

[0023] Figure 4 is another flow chart of a device collaborative processing method according to an embodiment of the present invention;

[0024] Figure 5 is another flow chart of a device collaborative processing method according to an embodiment of the present invention;

[0025] Figure 6 is another flow chart of a device collaborative processing method according to an embodiment of the present invention;

[0026] Figure 7 is another flow chart of a device collaborative processing method according to an embodiment of the present invention;

[0027] Figure 8 is a schematic diagram of a device coordination apparatus according to an embodiment of the present invention;

[0028] Figure 9 FIG. 1 is a schematic diagram of an edge gateway according to an embodiment of the present invention. DETAILED DESCRIPTION

[0029] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of them. All other embodiments obtained by ordinary technicians in this field based on the embodiments of the present invention without making any creative efforts shall fall within the scope of protection of the present invention.

[0030] The device collaborative processing method provided by the embodiment of the present invention can be applied in the following situations: Figure 1 In the application environment shown. Figure 1As shown, IoT devices communicate with edge gateways or IoT cloud platforms over the network. IoT devices, also known as user terminals, refer to programs that communicate with edge gateways or IoT cloud platforms and provide local services to clients. IoT devices include, but are not limited to, various personal computers, laptops, smartphones, tablets, cameras, and portable wearable devices. Communication with edge gateways or IoT cloud platforms can use standalone servers or cloud servers that provide basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms.

[0031] The device collaborative processing method provided by the embodiment of the present invention can be applied as follows: Figure 1 Specifically, the device collaborative processing method is applied in a device collaborative system, which includes Figure 1 The IoT device shown communicates with the edge gateway or IoT cloud platform. The IoT device communicates with the edge gateway or IoT cloud platform through the network, which is used to enable the edge gateway or IoT cloud platform to communicate with the IoT device for device collaborative processing to improve the stability of device collaboration.

[0032] Edge computing refers to providing local services close to the source of objects or data, using an open platform integrating core network, computing, storage, and application capabilities. Applications analyze and process data at the edge, eliminating data transfer and enabling faster network service responses. This meets the industry's fundamental needs for real-time services, application intelligence, security, and privacy protection, thereby reducing network traffic and response times.

[0033] Among them, the edge gateway, also known as the edge computing gateway, refers to any node with computing resources and network resources between the data source and the cloud center. By extending the functions of the IoT cloud platform to the edge gateway, the edge gateway can quickly and autonomously respond to events of IoT devices, providing low-latency, low-cost, privacy-protected, and locally autonomous local computing services.

[0034] IoT devices are non-standard computing devices that can connect wirelessly to a network and transmit data. The IoT involves expanding internet connectivity beyond standard devices like desktops, laptops, smartphones, and tablets to encompass a wide range of traditional, non-internet-enabled physical devices and everyday objects. By embedding appropriate processors in these devices, they can communicate and interact through IoT cloud platforms, allowing them to be remotely monitored and controlled.

[0035] In one embodiment, if Figure 2 As shown, a device collaborative processing method is provided, which is applied in Figure 1 The following steps are used as an example to illustrate the edge gateway in the example:

[0036] S201: Receive a to-be-processed task sent by a first device, where the to-be-processed task includes a task type and first data;

[0037] S202: Using a target collaborative microservice corresponding to the task type, collaboratively process the first data to obtain second data;

[0038] S203: If the task to be processed includes the second device identifier, sending the second data to the second device corresponding to the second device identifier;

[0039] S204: If the task to be processed does not include the second device identifier, the second data is stored in the local memory.

[0040] The first device is the device that sends the pending task. Depending on the pending task, it can be an IoT cloud platform, an IoT device, or an edge gateway. Correspondingly, the second device is the device that receives the second data. Depending on the pending task, it can be an IoT cloud platform, an IoT device, or an edge gateway. If the second device is not specified, the second data does not need to be sent accordingly.

[0041] As an example, in step S201, the edge gateway receives a pending task from the first device and executes subsequent steps based on the task type and first data in the pending task. The pending task can be triggered by a user through the first device, or it can be a pending task generated by the first device according to a rule or cycle, and the edge gateway performs the next step on the pending task.

[0042] In this example, the first data sent varies depending on the task type. The first device sends the corresponding first data according to the actual task type.

[0043] As an example, in step S202, after receiving a pending task sent by a first device, the edge gateway determines the task type of the pending task and collaboratively processes the first data using the target collaborative microservice corresponding to the task type, thereby obtaining processed second data. Depending on the task type, the second data may be sent to the second device or stored in local storage to efficiently complete the information transmission task.

[0044] In this example, the server will usually set up multiple microservices to implement corresponding functions, including but not limited to device management microservices, data storage microservices, and target collaboration microservices corresponding to various types of tasks in each example. They are set up according to business needs, and information is transmitted between each microservice through a message bus (message bus RabbitMq or message bus Kafka). They can be set up on the edge gateway or on an independent server. For example, the server with the target collaboration microservice installed is set between the edge gateway and the IoT device, or the server with the target collaboration microservice installed is set between the edge gateway and the IoT device, and between the edge gateway and the IoT cloud platform. The target collaboration microservice function is used to convert the data sent or received by each IoT device according to the corresponding protocol of its IoT device, thereby reducing the original reliance on device APIs or SDKs provided by third parties to access the IoT cloud platform. Among them, the protocols of IoT devices include but are not limited to Modbus protocol, HTTP(s) / CoAP protocol and MQTT protocol. The data format received or sent by the edge gateway and the IoT cloud platform is in JSON format.

[0045] As an example, in step S203, after the edge gateway obtains the second data processed by the target collaborative microservice, it determines whether the second data is sent to the second device based on whether the task to be processed includes the second device identifier, that is, whether the task type corresponding to the task to be processed needs to be forwarded. If the task to be processed includes the second device identifier, the second data is sent to the second device corresponding to the second device identifier, so that the second device processes the second data accordingly.

[0046] As an example, in step S204, after the edge gateway obtains the second data processed by the target collaborative microservice, it determines whether the second data is sent to the second device based on whether the task to be processed includes the second device identifier, that is, whether the task type corresponding to the task to be processed needs to be forwarded. If the task to be processed does not include the second device identifier, the second data is stored in the local memory.

[0047] In this example, by receiving the task to be processed sent by the first device, the target collaborative microservice is used to collaboratively process the first data in the task to be processed according to the task type in the task to be processed, thereby obtaining the processed and converted second data. By using the target collaborative microservice to process the first data, the dependence on the third-party API or SDK is reduced; if the task to be processed includes a second device identifier, the second data is sent to the second device corresponding to the second device identifier. If the task to be processed does not include the second device identifier, the second data is stored in the local memory, so that the second data processed by the target collaborative microservice will be forwarded accordingly according to the requirements of the task to be processed, so as to improve the stability of the connection between the first device, the second device and the edge gateway.

[0048] In one embodiment, if Figure 3 As shown, if the task type includes a protocol access task, the task to be processed further includes a first device identifier and a second device identifier, and the first data includes a first device attribute;

[0049] Step S202, using the target collaborative microservice corresponding to the task type to collaboratively process the first data to obtain second data, includes:

[0050] S301: If the task type is a protocol access task, determining a first device protocol corresponding to the first device identifier according to the first device identifier;

[0051] S302: Using the protocol access microservice corresponding to the protocol access task, perform protocol access collaborative processing on the first device protocol and the first device attribute to obtain second data.

[0052] Among them, the protocol access task is to connect the first device to the target collaborative microservice of the edge gateway so that the target collaborative microservice can identify the first device attributes of the first device, and convert the first data according to the corresponding first device protocol into second data that can be recognized by the second device.

[0053] When the task type includes a protocol access task, the task to be processed includes a second device identifier, that is, sending the second data of the device access result to the second device corresponding to the second device identifier.

[0054] Understandably, when the edge gateway is disconnected from the IoT cloud platform, the edge gateway can still communicate with the IoT devices through the target collaboration microservices.

[0055] As an example, in step S301, after confirming the task type, if the task type is a protocol access task, the edge gateway confirms the first device protocol corresponding to the first device identifier based on the first device identifier carried by the first data sent by the first device, so as to store and process the device protocol corresponding to the device access of the target collaborative microservice.

[0056] In this example, the message format and content of device-to-device interactions vary depending on the protocol. Therefore, if the device protocol corresponding to a device changes, the module associated with the device access will also change. In this example, the master control module identifies the corresponding protocol based on the first device identifier. If the first device is a CoAP device, the corresponding CoAP protocol is determined.

[0057] As an example, in step S302, after obtaining the first device protocol, the edge gateway uses the protocol access microservice corresponding to the protocol access task, stores the confirmed first device protocol and the corresponding first device attributes in the device cache module corresponding to the protocol access microservice, and generates a device access result as the second data for sending to the second device.

[0058] In this example, when the first device is an IoT device, the second device is the corresponding IoT cloud platform. After storing the device protocol and device attributes corresponding to the IoT device, the protocol access microservice corresponding to the protocol access task generates the corresponding device access result as the second data, which is then sent to the IoT cloud platform. The first device identifier includes the object model ID and the device ID, which are used to confirm the device's identity and improve the security and stability of data transmission.

[0059] The first device attribute is set according to the different physical model functions of the first device. For example, the physical model function is defined as a temperature sensor. It is a physical model with temperature as its corresponding attribute. Its corresponding first device attribute includes temperature data. The first device attribute also includes specific information and status during device operation.

[0060] Furthermore, the protocol access microservice includes a master control module, a protocol conversion module, and a device cache module. The master control module is used to receive pending tasks from the IoT cloud platform or IoT devices, identify them, and execute them; the device cache module is used to store the device attributes and device protocols of each IoT device, such as device attributes (device ID), collection frequency (sampling interval), and protocol parameters (network interface, communication rate, etc.); and the protocol conversion module is used to perform protocol conversion on pending tasks.

[0061] In this example, if the master control module of the protocol access microservice collects the data upload task sent by the IoT device, it identifies the corresponding IoT device identifier to determine the IoT device attributes and IoT device protocol, and uses a pluggable protocol to convert the data corresponding to the data upload task into the corresponding JSON format and send it to the IoT cloud platform; if the master control module of the protocol access microservice receives the command issuance task sent by the IoT cloud platform, it converts the command operation content corresponding to the command issuance task into the format of the IoT device protocol based on the IoT device identifier to be received, and uses a pluggable protocol to determine the IoT device attributes and IoT device protocol, and sends it to the IoT device. It can also issue commands periodically according to the collection frequency in the command operation content.

[0062] In this example, if the task type is a protocol access task, the first device protocol corresponding to the first device identifier is determined based on the first device identifier, and the first device protocol and the first device attribute in the first data are stored in the protocol access microservice, and the second data is obtained to complete the device access. This ensures that in subsequent processing, the protocol access microservice can perform format conversion on the data sent according to the first device identifier and the second device identifier, thereby improving the stability of data transmission.

[0063] In one embodiment, if Figure 4 As shown, if the task type includes a command issuing task, the task to be processed includes a second device identifier, and the first data includes command operation content;

[0064] Step S202, using the target collaborative microservice corresponding to the task type to collaboratively process the first data to obtain second data, includes:

[0065] S401: If the task type includes a command issuing task, determining a second device protocol corresponding to the second device identifier according to the second device identifier;

[0066] S402: Using the command issuing microservice corresponding to the command issuing task, perform data conversion and collaborative processing on the second device protocol and the command operation content to obtain second data.

[0067] Among them, the command issuing task is that the first device issues the command operation content according to business needs so that the second device can execute it. The first device corresponding to the command issuing task includes an edge gateway or an IoT cloud platform. After converting the command operation content according to the second device protocol, the command operation content is sent to the corresponding second device. The second device can respond to the command, but cannot send commands in reverse.

[0068] As an example, in step S401, after the edge gateway confirms the task type, if the task type is a command issuing task, it confirms the second device protocol corresponding to the second device identifier based on the second device identifier corresponding to the task to be processed, so as to process the command operation content corresponding to the first data.

[0069] In this example, if the command operation content is data sampling of an IoT device, which includes an acquisition frequency, the corresponding command operation content is periodically issued through the acquisition frequency. For example, the attribute information corresponding to a certain IoT device is a temperature sensor, and the corresponding acquisition frequency is 60s. Then, based on the device identifier, the command operation content is converted into a message of the corresponding protocol that the device can accept, that is, the second data. Among them, the use of the acquisition frequency is different depending on the protocol. For protocols like modbus, it is necessary to send a sampling request every acquisition frequency for data sampling; for protocols like http, it is sufficient to send a sampling request once, and then transmit the acquisition frequency to the device. The device will report data once every acquisition frequency interval.

[0070] As an example, in step S402, after the edge gateway determines the second device protocol corresponding to the second device identifier, the command issuing microservice corresponding to the command issuing task converts the command operation content corresponding to the first data into second data in the format corresponding to the second device protocol, so as to provide it to the second device for identification and execution, thereby ensuring that the first device calls the second device.

[0071] In this example, the command issuance microservice is used to receive the command operation content in the first data of the first device (edge ​​gateway or IoT cloud platform) connected to the bus, send the corresponding command operation content according to the second device attribute corresponding to the second device (IoT device) (for example, the second device is temperature), and use the protocol conversion module to perform data conversion to convert the command operation content into second data that can be recognized by the second device.

[0072] In this example, if the task type includes a command issuing task, the second device protocol corresponding to the second device identifier is determined based on the second device identifier, and the command issuing microservice corresponding to the command issuing task is used to perform data conversion and collaborative processing on the second device protocol and the command operation content, and convert the command operation content into second data that can be recognized by the second device, thereby improving the efficiency of issuing the command issuing task.

[0073] In one embodiment, if Figure 5 As shown, if the task type includes an engine synchronization task, the task to be processed includes a second device identifier, and the first data includes an engine version identifier;

[0074] Step S202, using the target collaborative microservice corresponding to the task type to collaboratively process the first data to obtain second data, includes:

[0075] S501: If the task type includes an engine synchronization task, determine whether a local rule engine corresponding to the engine version identifier exists in the local storage according to the engine version identifier;

[0076] S502: If a local rule engine exists, use the first engine synchronization microservice corresponding to the engine synchronization task to check the local rule engine and obtain the second data;

[0077] S503: If there is no local rule engine, the second engine synchronization microservice corresponding to the engine synchronization task is used to perform engine synchronization collaborative processing on the version rule engine corresponding to the engine version identifier to obtain the second data.

[0078] The engine synchronization task involves updating the rules engine of the IoT cloud platform (the first device) to an edge gateway closer to the device. This allows the edge gateway to quickly and autonomously respond to local IoT device events based on the local rules engine. The task type is an engine synchronization task, and the first device is used as the second device identifier. Feedback based on the engine synchronization status of the edge gateway is provided to ensure the smooth progress of the engine synchronization task.

[0079] Among them, the rule engine identifies and judges the collected data corresponding to the collected IoT devices, and performs corresponding execution when the collected data meets the standards. For example, if the temperature value of IoT device A is greater than 50 degrees, the command operation content to cool down IoT device B is sent to IoT device B for collaborative linkage.

[0080] Understandably, when the edge gateway is disconnected from the IoT cloud platform, the local rule engine of the edge gateway can still be used for corresponding linkage without affecting other computing services on the edge gateway.

[0081] As an example, in step S501, after the edge gateway confirms the task type, if the task type is an engine synchronization task, it uses the engine version identifier in the task type to determine whether there is a local rule engine corresponding to the engine version identifier in the local memory, thereby determining whether synchronization is required and reducing the waste of computing resources.

[0082] In one example, the engine version identifier can be used to determine whether the local rule engine of the edge gateway needs to be updated, thereby ensuring that the functions of the rule engine are updated in a timely manner and improving the stability of the IoT system.

[0083] As an example, in step S502, if a local rule engine exists in the local storage corresponding to the edge gateway, the first engine synchronization microservice corresponding to the engine synchronization task performs data verification on the local rule engine and generates an engine synchronization result as the second data, that is, the engine synchronization result passes the local verification and no engine synchronization operation is required.

[0084] In this example, the first engine synchronization microservice is used to verify the data files corresponding to the local rule engine according to the engine version identifier to determine the integrity of the local rule engine, thereby improving the stability of the local rule engine.

[0085] In one example, the local rule engine of the edge gateway can also be checked by the engine version identifier. If the local rule engine fails, the local rule engine can be synchronized according to the engine version identifier.

[0086] As an example, in step S503, if there is no local rule engine in the local storage corresponding to the edge gateway, it is considered that the version of the local rule engine of the edge gateway is older, or the local rule engine corresponding to the engine version identifier is not set. The second engine synchronization microservice corresponding to the engine synchronization task downloads or sends the corresponding version rule engine according to the first data through the engine version identifier for synchronization processing, and generates an engine synchronization result as the second data, that is, the engine synchronization result is the completion of the synchronization operation.

[0087] In this example, the second engine synchronization microservice is used to synchronize the version rule engine corresponding to the engine version identifier to the local storage when there is no local rule engine to complete the engine synchronization task.

[0088] In this example, if the task type includes an engine synchronization task, the engine version identifier is used to determine whether there is a local rule engine corresponding to the engine version identifier in the local storage. If a local rule engine exists, the first engine synchronization microservice corresponding to the engine synchronization task is used to perform data verification on the local rule engine to determine the integrity of the local rule engine, and generate an engine synchronization result as the second data; if there is no local rule engine, the second engine synchronization microservice corresponding to the engine synchronization task is used to perform engine synchronization collaborative processing on the version rule engine corresponding to the engine version identifier, and synchronize the version rule engine to the edge gateway in a timely manner to ensure the update of the local rule engine of the edge gateway, thereby improving the stability of the local rule engine.

[0089] In one embodiment, if Figure 6 As shown, if the task type includes a data upload task, the task to be processed includes the first device identifier but does not include the second device identifier, and the first data includes the first device protocol;

[0090] Step S202, using the target collaborative microservice corresponding to the task type to collaboratively process the first data to obtain second data, includes:

[0091] S601: If the task type includes a data upload task, determining a first device protocol corresponding to the first device identifier according to the first device identifier;

[0092] S602: Using the data upload microservice corresponding to the data upload task, perform data conversion on the first device protocol and the first data to obtain second data.

[0093] The data upload task involves uploading collected data or alarm events from the first device, i.e., an IoT device, so that the second device, i.e., an edge gateway or IoT cloud platform, can use a local rule engine to perform corresponding rule judgment and collaborative linkage. Alarm events include information, alarms, and faults that the first device needs to perceive and process externally.

[0094] In one example, a data upload task can provide feedback based on the command content. Alternatively, the task can periodically upload the first data based on the collection frequency corresponding to the command content, without receiving the command content. The collection frequency refers to the interval at which the device uploads the attribute data corresponding to the collected data. For example, 60 seconds means that the attribute value is uploaded every 60 seconds. Specifically, the attribute data of the device attributes, such as the temperature attribute and temperature value corresponding to a temperature sensor, are uploaded.

[0095] As an example, in step S601, after confirming the task type, if the task type is a data upload task, the edge gateway determines the first device protocol corresponding to the first device identifier based on the first device identifier to convert the first data into the data format of the first device protocol.

[0096] As an example, in step S602, after confirming the first device protocol, the edge gateway uses the data upload microservice corresponding to the data upload task to convert the first data according to the first device protocol to obtain second data, which is then sent to the corresponding second device. In this example, when the first device is an IoT device, the first data is converted into second data in JSON format according to the IoT device protocol and sent to the corresponding edge gateway or IoT cloud platform for processing.

[0097] In this example, the data upload microservice is used to receive the first data (collected data) of the first device (Internet of Things device), obtain the corresponding first device protocol from the device cache module according to the first device identifier, and then use the protocol conversion module to perform data conversion, converting the collected data into second data in Json format that can be recognized by the second device.

[0098] In this example, if the task type includes a data upload task, the first device protocol corresponding to the first device identifier is determined based on the first device identifier, and the first device protocol and the first data are converted by adopting the data upload microservice corresponding to the data upload task, so as to convert the first data into second data in a format that can be recognized by the second device, thereby improving the efficiency of data collection of the data upload task.

[0099] In one embodiment, if Figure 7 As shown, in step S204, if the task to be processed does not include the second device identifier, the second data is stored in the local memory, including:

[0100] S701: Using a local rule engine, matching rules based on the first device identifier to confirm the first device rule;

[0101] S702: Identify the second data according to the first device rule and obtain an engine identification result;

[0102] S703: If the engine recognition result satisfies the local rule engine, a command issuing task and command operation content are generated.

[0103] Among them, if the task to be processed does not include the second device identification, the task type is usually a data upload task. Through the edge gateway, the second data corresponding to the first device after data conversion, that is, the collected data corresponding to the Internet of Things device, is identified and judged using the local rule engine, thereby improving the processing efficiency of the events corresponding to the Internet of Things device and reducing the computing burden of the Internet of Things cloud platform.

[0104] As an example, in step S701, when the task type is a data upload task, the edge gateway obtains the corresponding second data, uses the local rule engine to identify it, first matches the rules through the first device identifier, and obtains the first device rules corresponding to the first device, which are used to perform rule judgment on the second data corresponding to different first devices.

[0105] In this example, if IoT device A needs to make a judgment based on data collected by the temperature sensor of the device, after confirming that the first device is IoT device A, the device rule corresponding to IoT device A is confirmed.

[0106] As an example, in step S702, after confirming the first device rule, the edge gateway identifies the second data based on the first device rule and obtains an engine recognition result, where the engine recognition result includes whether it satisfies the local rule engine or not. In this example, if the data collected by the temperature sensor of IoT device A is greater than 50 degrees Celsius, and the first device rule requires that the temperature cannot exceed 40 degrees Celsius, the condition for triggering the local rule engine is met, the local rule engine is satisfied, and the corresponding engine recognition result is output.

[0107] As an example, in step S703, after the edge gateway obtains the engine recognition result, if the engine recognition result satisfies the local rule engine, it generates a command issuing task and command operation content, and generates a corresponding command issuing task.

[0108] In this example, if the temperature value corresponding to IoT device A satisfies the local rule engine, a command operation content is generated to instruct IoT device B to cool down, and IoT device B is used as the second device to send the command task to IoT device B for collaborative linkage.

[0109] In another example, when the IoT cloud platform is disconnected, the edge gateway is used for collaborative linkage, which is triggered by the association between different devices. For example, if the temperature value of IoT device A is 50 degrees, and the local rule engine determines that it exceeds the rule corresponding to the temperature value of IoT device A, the fan of IoT device B will be triggered to start. Among them, the specific logic does not need to be sent to the disconnected IoT cloud platform through the bus. The scenario linkage microservice in the edge gateway can be used to read the sampling data of IoT device A from the bus (the bus of the edge gateway is written to the bus after receiving the collected data by the protocol access microservice for other microservices to read), and then determine whether the rule is triggered. If triggered, the corresponding call command is issued through the edge gateway. The microservice sends a command to IoT device B to issue a task, thereby realizing the edge gateway's control over the IoT devices and achieving the effect of collaborative linkage.

[0110] In this example, a local rule engine is used to match rules based on the first device identifier, confirm the first device rules, and identify the second data, thereby obtaining the engine identification result corresponding to the second data uploaded by the first device, so as to perform corresponding collaborative linkage operations. If the engine identification result satisfies the local rule engine, a command issuance task and command operation content are generated, thereby instructing the command issuance task to be executed on the corresponding second device, achieving the effect of collaborative linkage, thereby improving the processing efficiency of corresponding events of the Internet of Things devices and reducing the computing burden of the Internet of Things cloud platform.

[0111] It should be understood that the size of the serial numbers of the steps in the above embodiments does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0112] In one embodiment, a device coordination apparatus is provided, which corresponds one-to-one to the device coordination processing method in the above embodiment. Figure 8 As shown, the device collaboration apparatus includes a task receiving module 801, a second data acquisition module 802, a second data sending module 803, and a second data storage module 804. The functional modules are described in detail as follows:

[0113] The pending task receiving module 801 is configured to receive a pending task sent by a first device, where the pending task includes a task type and first data;

[0114] The second data acquisition module 802 is configured to collaboratively process the first data using a target collaborative microservice corresponding to the task type to acquire second data;

[0115] A second data sending module 803 is configured to send the second data to the second device corresponding to the second device identifier if the task to be processed includes the second device identifier;

[0116] The second data storage module 804 is configured to store the second data in the local memory if the task to be processed does not include the second device identifier.

[0117] In one embodiment, the second data acquisition module 802 includes:

[0118] a first device protocol confirmation unit configured to determine, if the task type is a protocol access task, a first device protocol corresponding to the first device identifier based on the first device identifier;

[0119] The second data acquisition unit is configured to adopt the protocol access microservice corresponding to the protocol access task to perform protocol access collaborative processing on the first device protocol and the first device attribute to acquire second data.

[0120] In one embodiment, the second data acquisition module 802 includes:

[0121] a second device protocol determining unit, configured to determine, based on the second device identifier, a second device protocol corresponding to the second device identifier if the task type includes a command issuing task;

[0122] The second data acquisition unit is used to use the command issuing microservice corresponding to the command issuing task to perform data conversion and collaborative processing on the second device protocol and the command operation content to obtain second data.

[0123] In one embodiment, the second data acquisition module 802 includes:

[0124] A local rule engine detection unit, configured to determine, if the task type includes an engine synchronization task, whether a local rule engine corresponding to the engine version identifier exists in the local storage according to the engine version identifier;

[0125] The second data acquisition unit is used to, if a local rule engine exists, use the first engine synchronization microservice corresponding to the engine synchronization task to verify the local rule engine and obtain the second data; if no local rule engine exists, use the second engine synchronization microservice corresponding to the engine synchronization task to perform engine synchronization collaborative processing on the version rule engine corresponding to the engine version identifier to obtain the second data.

[0126] In one embodiment, the second data acquisition module 802 includes:

[0127] a first device protocol confirmation unit, configured to determine, based on the first device identifier, a first device protocol corresponding to the first device identifier if the task type includes a data upload task;

[0128] The second data acquisition unit is used to use the data upload microservice corresponding to the data upload task to perform data conversion on the first device protocol and the first data to obtain second data.

[0129] In one embodiment, the second data storage module 804 includes:

[0130] A first device rule confirmation unit, configured to use a local rule engine to perform rule matching according to the first device identifier and confirm the first device rule;

[0131] an engine recognition result obtaining unit, configured to identify the second data according to the first device rule and obtain an engine recognition result;

[0132] The command issuing task generating unit is used to generate the command issuing task and command operation content if the engine recognition result satisfies the local rule engine.

[0133] For the specific definition of the device collaboration device, please refer to the definition of the device collaborative processing method above, which will not be repeated here. Each module in the above-mentioned device collaboration device can be implemented in whole or in part by software, hardware, and a combination thereof. The above-mentioned modules can be embedded in or independent of the processor in the edge gateway in hardware form, or can be stored in the memory of the edge gateway in software form, so that the processor can call and execute the operations corresponding to the above modules.

[0134] In one embodiment, an edge gateway is provided. The edge gateway may be a server, and its internal structure diagram may be as follows: Figure 8As shown. The edge gateway includes a processor, memory, network interface and database connected via a system bus. The processor of the edge gateway is used to provide computing and control capabilities. The memory of the edge gateway includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and computer program in the non-volatile storage medium. The database of the edge gateway is used to execute data adopted or generated in the process of the device collaborative processing method. The network interface of the edge gateway is used to communicate with an external terminal via a network connection. When the computer program is executed by the processor, a device collaborative processing method is implemented.

[0135] In one embodiment, an Internet of Things system is provided, including an edge gateway, and also including an Internet of Things cloud platform and an Internet of Things device that communicate with the edge gateway; when the Internet of Things cloud platform is the first device, the Internet of Things device is the second device; or, the Internet of Things device or the edge gateway is the first device, and the Internet of Things cloud platform is the second device.

[0136] In one embodiment, an edge gateway is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the device collaborative processing method in the above embodiment is implemented, for example Figure 2 S201-S204 shown, or Figures 3 to 7 Alternatively, when the processor executes the computer program, the functions of each module / unit in the embodiment of the device coordination device are realized, for example Figure 8 The functions of the to-be-processed task receiving module 801 , the second data acquiring module 802 , the second data sending module 803 and the second data storing module 804 are not described here in detail to avoid repetition.

[0137] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the device collaborative processing method in the above embodiment is implemented, for example Figure 2 S201-S204 shown, or Figures 3 to 7 Alternatively, when the computer program is executed by the processor, the functions of the modules / units in the embodiment of the device collaboration device are realized, for example Figure 8 The functions of the to-be-processed task receiving module 801 , the second data acquiring module 802 , the second data sending module 803 and the second data storing module 804 are not described here in detail to avoid repetition.

[0138] Those skilled in the art will appreciate that all or part of the processes in the above-described embodiment methods can be implemented by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the above-described embodiment methods. Among them, any reference to memory, storage, database or other media used in the embodiments provided by the present invention can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0139] Those skilled in the art will clearly understand that for the sake of convenience and brevity of description, only the division of the above-mentioned functional units and modules is used as an example. In actual applications, the above-mentioned functions can be distributed and completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0140] The above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit the same. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the various embodiments of the present invention, and should all be included in the scope of protection of the present invention.

Claims

1. A device collaborative processing method, characterized in that: include: receiving a to-be-processed task sent by a first device, where the to-be-processed task includes a task type and first data; Using the target collaborative microservice corresponding to the task type to collaboratively process the first data to obtain second data; If the task to be processed includes a second device identifier, sending the second data to a second device corresponding to the second device identifier; If the task to be processed does not include the second device identifier, storing the second data in a local memory; Wherein, if the task type includes a protocol access task, the task to be processed further includes a first device identifier and a second device identifier, and the first data includes a first device attribute; The adopting the target collaborative microservice corresponding to the task type to collaboratively process the first data to obtain the second data includes: If the task type is a protocol access task, determining a first device protocol corresponding to the first device identifier according to the first device identifier; The protocol access microservice corresponding to the protocol access task is used to perform protocol access collaborative processing on the first device protocol and the first device attribute to obtain second data.

2. The device collaborative processing method according to claim 1, wherein: If the task type includes a command issuing task, the task to be processed includes a second device identifier, and the first data includes command operation content; The adopting the target collaborative microservice corresponding to the task type to collaboratively process the first data to obtain the second data includes: If the task type includes a command issuing task, determining a second device protocol corresponding to the second device identifier according to the second device identifier; The command issuing microservice corresponding to the command issuing task is used to perform data conversion and collaborative processing on the second device protocol and the command operation content to obtain second data.

3. The device collaborative processing method according to claim 1, wherein: If the task type includes an engine synchronization task, the to-be-processed task includes a second device identifier, and the first data includes an engine version identifier; The adopting the target collaborative microservice corresponding to the task type to collaboratively process the first data to obtain the second data includes: If the task type includes an engine synchronization task, determining, based on the engine version identifier, whether a local rule engine corresponding to the engine version identifier exists in the local storage; If the local rule engine exists, the first engine synchronization microservice corresponding to the engine synchronization task is used to check the local rule engine to obtain the second data; If the local rule engine does not exist, the second engine synchronization microservice corresponding to the engine synchronization task is used to perform engine synchronization collaborative processing on the version rule engine corresponding to the engine version identifier to obtain the second data.

4. The device collaborative processing method according to claim 1, wherein: If the task type includes a data upload task, the to-be-processed task includes a first device identifier but does not include a second device identifier, and the first data includes a first device protocol; The adopting the target collaborative microservice corresponding to the task type to collaboratively process the first data to obtain the second data includes: If the task type includes a data upload task, determining a first device protocol corresponding to the first device identifier according to the first device identifier; The data upload microservice corresponding to the data upload task is used to perform data conversion on the first device protocol and the first data to obtain second data.

5. The device collaborative processing method according to claim 1, wherein: If the task to be processed does not include the second device identifier, after storing the second data in the local memory, the device collaborative processing method further includes: Using a local rule engine, performing rule matching according to the first device identifier, and confirming the first device rule; Identify the second data according to the first device rule and obtain an engine identification result; If the engine recognition result satisfies the local rule engine, a command issuing task and command operation content are generated.

6. A device coordination apparatus, characterized in that: include: a pending task receiving module, configured to receive a pending task sent by a first device, wherein the pending task includes a task type and first data; A second data acquisition module is configured to collaboratively process the first data using a target collaborative microservice corresponding to the task type to acquire second data; a second data sending module, configured to send the second data to a second device corresponding to the second device identifier if the task to be processed includes a second device identifier; A second data storage module, configured to store the second data in a local memory if the task to be processed does not include a second device identifier; Wherein, if the task type includes a protocol access task, the task to be processed further includes a first device identifier and a second device identifier, and the first data includes a first device attribute; The second data acquisition module is also used to determine the first device protocol corresponding to the first device identifier based on the first device identifier if the task type is a protocol access task; use the protocol access microservice corresponding to the protocol access task to perform protocol access collaborative processing on the first device protocol and the first device attribute to obtain second data.

7. An edge gateway comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the computer program, the device collaborative processing method according to any one of claims 1 to 5 is implemented.

8. An Internet of Things system, comprising the edge gateway of claim 7, and further comprising an Internet of Things cloud platform and an Internet of Things device communicating with the edge gateway; The IoT cloud platform is the first device, and the IoT device is the second device; Alternatively, the Internet of Things device or the edge gateway is the first device, and the Internet of Things cloud platform is the second device.

9. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the device collaborative processing method according to any one of claims 1 to 5 is implemented.

Images