Data processing method, Internet of Things system, electronic equipment, storage medium and product

Abstract

The invention provides a data processing method, an Internet of Things system, an electronic device, a storage medium and a product, the data processing method is applied to a server of the Internet of Things system, and the method comprises the following steps: receiving target data, the target data being associated with an Internet of Things device; based on a target type of the target data, determining a target routing rule matched with the target data, the target type being determined according to a field in the target data; and routing the target data to the target message middleware according to the target routing rule. According to the technical scheme, the data transmission efficiency can be improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of Internet of Things, and in particular to a data processing method, an Internet of Things system, an electronic device, a storage medium and a computer program product. BACKGROUND

[0002] The rise of the Internet of Vehicles (a kind of Internet of Things) makes the interaction between vehicles and between vehicles and the cloud more closely. Vehicles need to send data to the cloud, and the cloud needs to be routed to the message middleware after receiving the data, so as to call the related data subsequently. However, the data routing path cannot be flexibly configured at present. SUMMARY

[0003] In order to solve the above problems, the present application provides a data processing method, an Internet of Things system, an electronic device, a storage medium and a computer program product.

[0004] In a first aspect, the present application provides a data processing method applied to a server of an Internet of Things system, and the method comprises: receiving target data, the target data being associated with an Internet of Things device; determining a target routing rule matched with the target data based on a target type of the target data, the target type being determined according to a field in the target data; and routing the target data to a target message middleware according to the target routing rule.

[0005] In combination with the first aspect, the target data is received from an Internet of Things device by a load balancer of the Internet of Things system and is sent based on a load balancing strategy.

[0006] In combination with the first aspect, the determination of the target routing rule matched with the target data based on the target type of the target data comprises: obtaining a preconfigured routing rule set, the preconfigured routing rule set comprising a plurality of routing rules, each routing rule corresponding to at least one type; and determining the target routing rule based on the target type and the preconfigured routing rule set.

[0007] In combination with the first aspect, the determination of the target routing rule based on the target type and the preconfigured routing rule set comprises: if there is no routing rule matched with the target type in the preconfigured routing rule set, generating a new routing rule based on the target type, and determining the new routing rule as the target routing rule.

[0008] In combination with the first aspect, before the determination of the target routing rule matched with the target data based on the target type of the target data, the method further comprises: analyzing the target data to obtain an analysis result; and determining that the target data needs to be routed to the target message middleware based on the analysis result.

[0009] In combination with the first aspect, before receiving the target data, the method further comprises: performing security authentication in response to a connection request from the Internet of Things device; and establishing a communication connection between the server and the Internet of Things device if the security authentication is passed.

[0010] In combination with the first aspect, the security authentication comprises at least one of the following: verifying validity of a certificate of the Internet of Things device; verifying consistency between a device identifier of the Internet of Things device and an identification code in the certificate; determining whether there is data of the Internet of Things device in the Internet of Things system; and determining whether the Internet of Things device is connected to the server through a unique connection channel.

[0011] In the second aspect, the application further provides a data processing method applied to a message middleware of an Internet of Things system, the method comprising: receiving target data sent by a server in the Internet of Things system, wherein the target data is sent by the server based on the method described above.

[0012] In the third aspect, the application further provides a data processing method applied to a load balancer of an Internet of Things system, the method comprising: receiving target data from an Internet of Things device; forwarding the target data to a target server, so that the target server determines a target routing rule matched with the target data based on a target type of the target data, and the target type is determined according to a field in the target data; and routing the target data to a target message middleware according to the target routing rule.

[0013] In combination with the third aspect, before receiving the target data from the Internet of Things device, the method further comprises: receiving a connection request from the Internet of Things device; and forwarding the connection request to the target server according to a load balancing strategy, so that the target server performs the connection request.

[0014] In the fourth aspect, the application further provides a data processing method applied to an Internet of Things device of an Internet of Things system, the method comprising: sending target data to a target server of the Internet of Things system, so that the target server performs the method described above.

[0015] In the fifth aspect, the application further provides an Internet of Things system comprising a server and at least one message middleware; the server is configured to: receive target data; and route the target data to the target message middleware according to a target routing rule matched based on a target type of the target data; wherein the target data is associated with an Internet of Things device, and the target type is determined according to a field in the target data; and the target message middleware is configured to: receive the target data forwarded by the server.

[0016] In combination with the fifth aspect, the Internet of Things system further comprises a load balancer configured to: forward a connection request sent by the Internet of Things device to the server, and / or forward target data sent by the Internet of Things device to the server.

[0017] In a sixth aspect, the present application provides a data processing apparatus applied to a server of an Internet of Things system, the data processing apparatus comprising: a first receiving module, a determining module and a routing module, wherein the first receiving module is configured to receive target data, the target data being associated with an Internet of Things device; the determining module is configured to determine a target routing rule matched with the target data based on a target type of the target data, the target type being determined according to a field in the target data; and the routing module is configured to route the target data to a target message middleware according to the target routing rule.

[0018] In a seventh aspect, the present application provides a data processing apparatus applied to a message middleware of an Internet of Things system, the data processing apparatus comprising a second receiving module configured to receive target data sent by a server of the Internet of Things system, wherein the target data is sent by the server based on the method described above.

[0019] In an eighth aspect, the present application provides a data processing apparatus applied to a load balancer of an Internet of Things system, the data processing apparatus comprising a third receiving module and a forwarding module, the third receiving module being configured to receive target data from an Internet of Things device; and the forwarding module being configured to forward the target data to a target server, so that the target server determines a target routing rule matched with the target data based on a target type of the target data, the target type being determined according to a field in the target data; and routes the target data to a target message middleware according to the target routing rule.

[0020] In a ninth aspect, the present application provides a data processing apparatus applied to an Internet of Things device of an Internet of Things system, the data processing apparatus comprising a sending module configured to send target data to a target server of the Internet of Things system, so that the target server executes the method described above.

[0021] In a tenth aspect, the present application provides an electronic device, comprising: a processor; a memory connected with the processor, the memory being configured to store a computer program, the computer program being configured to implement the method described above when executed by the processor.

[0022] In an eleventh aspect, the present application provides a storage medium, the storage medium storing a computer program, the computer program being configured to implement the method described above when executed by a processor.

[0023] In a twelfth aspect, the present application provides a computer program product comprising computer program instructions, the computer program instructions being configured to implement the method described above when executed by a processor.

[0024] In the data processing method provided in the present application, the server does not need to send data to the message middleware through the gateway plug-in, so that the server can flexibly select the most suitable message middleware for data forwarding and storage according to the characteristics (for example, type) of the target data, thereby improving the data transmission efficiency. In addition, the requirement that the Internet of Things device (for example, a vehicle) has classification ability is reduced, and the risk of data transmission failure caused by incorrect classification is reduced. BRIEF DESCRIPTION OF DRAWINGS

[0025] Figure 1 is a structural schematic diagram of an Internet of Things architecture in the prior art.

[0026] Figure 2 is a flowchart of a data processing method provided in an embodiment of the present application.

[0027] Figure 3 is a flowchart of a data processing method provided in another embodiment of the present application.

[0028] Figure 4 is a flowchart of a data processing method provided in another embodiment of the present application.

[0029] Figure 5 is a flowchart of a data processing method provided in another embodiment of the present application.

[0030] Figure 6 is a flowchart of a data processing method provided in another embodiment of the present application.

[0031] Figure 7 is a flowchart of a data processing method provided in another embodiment of the present application.

[0032] Figure 8 is a flowchart of a data processing method provided in another embodiment of the present application.

[0033] Figure 9 is a flowchart of a data processing method provided in another embodiment of the present application.

[0034] Figure 10 is a structural schematic diagram of an Internet of Things system provided in an embodiment of the present application.

[0035] Figure 11 is a structural schematic diagram of a data processing apparatus provided in an embodiment of the present application.

[0036] Figure 12 is a structural schematic diagram of a data processing apparatus provided in another embodiment of the present application.

[0037] Figure 13 is a structural schematic diagram of a data processing apparatus provided in another embodiment of the present application.

[0038] Figure 14 is a structural schematic diagram of a data processing apparatus provided by another embodiment of the present application.

[0039] Figure 15 is a structural schematic diagram of an electronic device provided by an embodiment of the present application. DETAILED DESCRIPTION

[0040] The technical solutions in the embodiments of the present application will be clearly and completely described in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only some of the embodiments of the present application, but not all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative work fall within the scope of protection of the present application.

[0041] Figure 1 is a structural schematic diagram of an Internet of Things architecture in the prior art. Optionally, the Internet of Things architecture can be a vehicle Internet of Things architecture. As shown in Figure 1 To ensure security in the process of data transmission, a gateway plug-in is usually deployed between a vehicle (one kind of Internet of Things device) and a server for security authentication of a Transport Layer Security (TLS), as shown in FIG. 1. The gateway plug-in can be an SS-based HAproxy gateway, which is a gateway architecture that combines HAProxy with a Shadowsocks (SS) proxy tool. By integrating the encryption transmission capability of the SS protocol at the HAProxy layer, the SS-based HAproxy gateway realizes a composite gateway that has the functions of load balancing, reverse proxying, and network traffic encryption. Since the HAproxy gateway is a third-party plug-in, when problem troubleshooting is needed, the troubleshooting difficulty is increased due to the third-party gateway, and the problem cannot be quickly troubleshooted and solved.

[0042] In addition, when the server forwards data to a message middleware, the gateway plug-in needs to be used, so the data forwarding path is preset by the gateway plug-in, which makes it impossible to change the routing forwarding path based on the own needs or flexibly configure a new data forwarding path. Specifically, a fixed topic is preset in the server, and the Internet of Things device (for example, a vehicle) classifies data in advance and then sends the classified data to the corresponding topic. The message middleware obtains the data according to the topic of the server, so the data forwarding path is preset and cannot be flexibly changed or a new forwarding path cannot be added, so it cannot adapt to the diversified data generated by the Internet of Things device. In addition, the existing solution requires the Internet of Things device to do the classification work, which has a high requirement for the Internet of Things device, and the Internet of Things device may send data to the wrong topic.

[0043] In the face of the above technical problems, an embodiment of the present application provides a data processing method, applied to a server of an Internet of Things system, the method comprising: receiving target data, the target data being associated with an Internet of Things device; determining a target routing rule matched with the target data based on a type of the target data; and routing the target data to a target message middleware according to the target routing rule. In the embodiment of the present application, the server does not need to send data to the message middleware through a gateway plug-in, so that the server can flexibly select the most suitable message middleware for data forwarding and storage according to the characteristics (for example, the type) of the target data, thereby improving the data transmission efficiency. In addition, the requirement that the Internet of Things device (for example, a vehicle) has classification capability is reduced, and the risk of data transmission failure caused by incorrect classification is reduced.

[0044] The following will be described in combination with Figures 2 to 9 The data processing method of the present application will be described in detail.

[0045] Figure 2 FIG. 1 is a flowchart of a data processing method provided by an embodiment of the present application. The data processing method is applied to a server of an Internet of Things system. Optionally, the Internet of Things system can be an Internet of Vehicles system, and the structure of the Internet of Things system can refer to FIG. 2. Figure 10 As shown in FIG. 3, the method comprises the following steps. Figure 2

[0046] Step S210, receiving target data.

[0047] The target data is associated with an Internet of Things device. In some embodiments, the target data is received by a load balancer of the Internet of Things system from the Internet of Things device and sent based on a load balancing strategy, so that the server overload can be avoided and the overall performance and stability of the Internet of Things system can be improved. Optionally, taking the Internet of Things device as a vehicle as an example, the target data can include vehicle state data (for example, vehicle speed, oil quantity, engine speed, tire pressure, remaining power, etc.), position information data (for example, driving track, latitude and longitude coordinates, etc.), sensor data (for example, road condition data collected by a camera, obstacle distance detected by a radar, etc.), user operation data (for example, vehicle door opening and closing state, air conditioning adjustment instruction, etc.) or fault diagnosis data, etc. The present application does not limit the target data, as long as it is data related to the Internet of Things device.

[0048] Step S220, determining a target routing rule matched with the target data based on a type of the target data.

[0049] ​In some embodiments, a plurality of types can be pre-configured for diversified data generated by the Internet of Things devices to facilitate classification of the data. Taking vehicle data as an example, the data can be classified according to the model of the vehicle, and the types of the data can be classified into vehicle brands, vehicle series, vehicle models, etc. The data can also be classified according to the data source, and the types of the data can be classified into vehicle control data, safety monitoring data, intelligent driving data, navigation data, entertainment data, etc. Alternatively, the data can be classified according to the real-time requirement of the data, and the types of the data can be classified into real-time data (e.g., laser radar point cloud data for automatic driving), near real-time data (e.g., vehicle speed data, rotation speed data, etc.), non-real-time data (e.g., air conditioning mode switching log, etc.), etc.

[0050] After obtaining the target data, the fields of the target data can be extracted, and the target type of the target data can be determined according to the fields, wherein the extraction of the fields can be achieved by analyzing the structured information of the target data. For example, by analyzing the target data, the extracted fields are the model information of the vehicle, and then the type of the target data can be determined to belong to the vehicle model according to the model information of the vehicle, and the specific vehicle model can be determined. For another example, by analyzing the target data, the fields of vehicle speed, rotation speed, etc. are extracted, and then the type of the target data can be determined to belong to vehicle control data according to the vehicle speed, rotation speed, etc. For another example, by analyzing the target data, the fields of latitude and longitude coordinates, driving trajectory data, etc. are extracted, and then the type of the target data can be determined to be navigation data according to the latitude and longitude coordinates, driving trajectory data, etc.

[0051] After determining the type of the target data, the target routing rule matching the target data can be determined based on the pre-configured routing rules, and the subsequent combination Figure 3 will be described in detail. In some embodiments, if there is no routing rule matching the target type in the pre-configured routing rule set, a new routing rule can be generated based on the target type, and the new routing rule is determined as the target routing rule, and the subsequent combination Figure 4 will be described in detail.

[0052] In step S230, the target data is routed to the target message middleware according to the target routing rule.

[0053] Optionally, the target message middleware includes at least one of Kafka, RabbitMQ, Redis, TimescaleDB, and HTTP Server. Different message middleware differ in throughput, latency, reliability, and functional characteristics. For example, Kafka is suitable for storing high-throughput, low-latency real-time vehicle data; RabbitMQ is suitable for storing data requiring richer routing strategies and reliable message delivery mechanisms; Redis is suitable for storing vehicle status data requiring fast access and low latency; TimescaleDB is suitable for processing time-series data, such as historical vehicle trajectory records; and HTTP Server is suitable for storing lightweight data, such as event notification data.

[0054] Each routing rule corresponds to a specific message middleware, or each routing rule corresponds to a queue under a message middleware; based on the target routing rule, target data can be routed to the target message middleware (e.g., a queue under the message middleware).

[0055] In this embodiment, the server does not need to send data to the message middleware via a gateway plugin. Therefore, the server can flexibly select the most suitable message middleware for data forwarding and storage based on the characteristics (e.g., type) of the target data, improving data transmission efficiency. Furthermore, the server can dynamically generate new routing rules to adapt to the diverse data types generated by IoT devices, avoiding the limitations of fixed topics in traditional solutions. Additionally, it reduces the requirement for IoT devices (e.g., vehicles) to have classification capabilities, minimizing the risk of data transmission failures due to misclassification.

[0056] The following is combined with Figure 3 and Figure 4 This example illustrates how to determine target routing rules.

[0057] Figure 3 This is a schematic flowchart of a data processing method provided in another embodiment of this application. Figure 2 Extending from the illustrated embodiment Figure 3 The illustrated embodiment will be described in detail below. Figure 3 The illustrated embodiments and Figure 2 The differences between the embodiments shown are not repeated here, and the similarities are not repeated here.

[0058] like Figure 3 As shown, in some embodiments, determining the target routing rule that matches the target data based on the type of target data (step S220) may include the following steps.

[0059] Step S310: Obtain the pre-configured routing rule set.

[0060] The pre-configured routing rule set includes multiple routing rules. The routing rules in the pre-configured routing rule set are pre-set. When setting each routing rule, the type of data that the current routing rule can transmit is determined. Therefore, each routing rule corresponds to at least one type.

[0061] Step S320: Determine the target routing rules based on the target type and the pre-configured routing rule set.

[0062] The server can match a target type with rules in a pre-configured routing rule set, and determine the routing rule that matches the target type as the target routing rule. For example, the pre-configured routing rule set can be stored in key-value pairs, where the key corresponds to the type and the value represents the routing rule corresponding to that type. The server retrieves the target type from the pre-configured routing rule set to determine the target routing rule. For instance, if the target type is vehicle control data, the server retrieves the routing rule corresponding to vehicle control data from the pre-configured routing rule set and determines that routing rule as the target routing rule. If the target type is navigation data, the server retrieves the routing rule corresponding to navigation data from the pre-configured routing rule set and determines that routing rule as the target routing rule.

[0063] In the embodiments of this application, determining the target routing rules based on the target type of the target data can effectively improve the flexibility and efficiency of data processing.

[0064] In some embodiments, with the development of IoT technology, the data generated by IoT devices may become more diverse. The currently set routing rules may not be able to cover new types of data generated subsequently. There may be situations where a matching routing rule cannot be found in the pre-configured routing rule set based on the new data type. The server in this embodiment can dynamically generate new routing rules based on the new type of target data. Please refer to [link / reference] for details. Figure 4 .

[0065] Figure 4 This is a schematic flowchart of a data processing method provided in another embodiment of this application. Figure 3 Extending from the illustrated embodiment Figure 4 The illustrated embodiment will be described in detail below. Figure 4 The illustrated embodiments and Figure 3 The differences between the embodiments shown are not repeated here, and the similarities are not repeated here.

[0066] like Figure 4 As shown, in some embodiments, determining the target routing rule based on the target type and the pre-configured routing rule set (step S320) may include the following steps.

[0067] Step S410: Determine whether there is a routing rule in the pre-configured routing rule set that matches the target type.

[0068] If a routing rule matching the target type exists in the pre-configured routing rule set, then step S420 is executed to determine the routing rule matching the target type as the target routing rule.

[0069] If there is no routing rule matching the target type in the pre-configured routing rule set, then step S430 is executed to generate a new routing rule based on the target type and to determine the new routing rule as the target routing rule.

[0070] For example, a target message middleware for receiving target data is determined based on the target type, and a new routing rule is generated based on the target message middleware to route the target data to the target message middleware. In some embodiments, the characteristics of the target data (e.g., real-time requirements, storage needs, processing priorities, etc.) may also be considered when selecting a message middleware, and a new routing rule may be generated based on the selected message middleware.

[0071] In some embodiments, new routing rules can be added to a pre-configured routing rule set for later use.

[0072] In this embodiment, new routing rules can be dynamically generated based on the target type of the target data, thereby better adapting to the diverse data types generated by IoT devices and improving the flexibility and efficiency of data processing. Furthermore, dynamically generating new routing rules can reduce reliance on pre-configured routing rule sets and lower the risk of data transmission failures due to missing routing rules.

[0073] As IoT devices become more functional, they generate massive amounts of data. If all this data were sent to a message middleware for storage, it would place a heavy burden on the middleware, potentially leading to performance degradation or even crashes. Therefore, this embodiment analyzes the target data and only routes it to the message middleware when it is determined that the data needs to be sent there. Please refer to [link / reference needed] for details. Figure 5 .

[0074] Figure 5 This is a schematic flowchart of a data processing method provided in another embodiment of this application. Figure 2 Extending from the illustrated embodiment Figure 5 The illustrated embodiment will be described in detail below. Figure 5 The illustrated embodiments and Figure 2 The differences between the embodiments shown are not repeated here, and the similarities are not repeated here.

[0075] like Figure 5 As shown, in some embodiments, before determining the target routing rule matching the target data based on the target type of the target data (step S220), the method further includes the following steps.

[0076] Step S510: Analyze the target data to obtain the analysis results.

[0077] After receiving the target data, the system analyzes it to determine whether it needs to be routed to the message middleware and generates analysis results. For example, the system analyzes the target data to determine if it is important data. If it is important data (e.g., vehicle safety-related data, intelligent driving-related data, navigation data, etc.), then it is determined that it needs to be routed to the message middleware; if it is not important data (e.g., vehicle status data such as fuel level, battery level, and on / off status, entertainment data, etc.), then it is determined that it does not need to be routed to the message middleware.

[0078] Step S520: Based on the analysis results, determine whether the target data needs to be routed to the target message middleware.

[0079] If the analysis results determine that the target data needs to be routed to the target message middleware, then step S220 is executed to determine the target routing rule that matches the target data based on the target type of the target data.

[0080] If the analysis results determine that the target data does not need to be routed to the target message middleware, then return to step S210 and continue receiving target data. Optionally, data that does not need to be routed to the target message middleware (e.g., low-priority or redundant data) can be discarded directly or stored in the server's local cache.

[0081] In this embodiment of the application, by analyzing the target data, unnecessary data transmission can be effectively reduced, the storage pressure of the message middleware can be reduced, thereby improving the overall performance and stability of the Internet of Things system; and the performance bottleneck of the message middleware caused by excessive data volume can be avoided, ensuring that important data can be transmitted and processed in a timely and efficient manner.

[0082] In some embodiments, before sending target data from an IoT device to the server, security authentication of the IoT device is required to improve data transmission security. Since the gateway plugin has been eliminated, in this embodiment, security authentication can be performed directly by the server. Please refer to [link / reference] for details. Figure 6 .

[0083] Figure 6 This is a schematic flowchart of a data processing method provided in another embodiment of this application. Figure 2 Extending from the illustrated embodiment Figure 6 The illustrated embodiment will be described in detail below. Figure 6 The illustrated embodiments and Figure 2 The differences between the embodiments shown are not repeated here, and the similarities are not repeated here.

[0084] like Figure 6As shown, in some embodiments, the method further includes the following steps before receiving the target data (step S210).

[0085] Step S610: In response to a connection request from an IoT device, perform security authentication.

[0086] Currently, the following issues have been discovered during testing and troubleshooting: IoT devices (e.g., vehicles) frequently encounter certificate usage errors when connecting to servers; expired or revoked certificates can also connect to servers and report data; IoT devices can still connect to servers and report data even if their device IDs cannot be found in the IoT system; and there are unstable interactions between IoT devices and the IoT system, all of which lead to data security issues.

[0087] Therefore, this application embodiment employs a combination of multiple authentication methods when performing security authentication on IoT devices to ensure the security of IoT access. Optionally, performing security authentication includes at least one of the following methods: verifying the validity of the IoT device's certificate; verifying the consistency between the IoT device's device identifier and the identification code (e.g., Vehicle Identification Number, VIN) in the certificate; determining whether IoT device data exists in the IoT system; and determining that the IoT device communicates with the server through a unique connection channel.

[0088] Optionally, verifying the validity of the IoT device's certificate includes: sending the IoT device's certificate to the Online Certificate Status Protocol (OCSP) for verification; if the certificate status is expired or revoked, it is determined that the IoT device has failed security authentication, the server is refused to establish a communication connection with the IoT device, and the IoT device's identification code (e.g., vehicle identification code) is stored in a first database (e.g., Redis). Optionally, when the number of IoT devices corresponding to the identification codes in the first database is greater than or equal to a first preset threshold, the identification codes stored in the first database are exported and sent to relevant users, such as operators, so that operators can take appropriate measures. The first preset threshold can be manually set. For example, when a vehicle's certificate is revoked by the automaker due to a leaked certificate private key, when the vehicle initiates a connection request, the OCSP verification returns a "revoked" status, and the server can refuse its access accordingly, effectively preventing unauthorized access by malicious devices and improving data security.

[0089] Optionally, verifying the consistency between the IoT device's device identifier and the identification code in the certificate includes: extracting the identification code contained in the IoT device's certificate; if the identification code in the certificate does not match the IoT device's identification code, it is determined that the IoT device has failed security authentication, the server is refused to establish a communication connection with the IoT device, and the IoT device's identification code is stored in a second database (e.g., Redis). For example, the IoT device's certificate contains a field for the identification code; the identification code is extracted from the certificate; then, the actual identification code of the IoT device is queried in the device information database using the device identifier (e.g., a unique device identifier or device ID) carried by the IoT device in the connection request. If the two are inconsistent, for example, the VIN in the certificate corresponds to vehicle A, while the VIN of the vehicle initiating the connection request corresponds to vehicle B, then security authentication is deemed to have failed. This effectively prevents attackers from using forged certificates of other vehicles to impersonate the user, ensuring the authenticity of the access vehicle's identity and further improving data security.

[0090] Optionally, when the number of IoT devices corresponding to the identification codes in the second database is greater than or equal to a second preset threshold, the identification codes stored in the second database are exported and sent to relevant users, such as operators, so that operators can take appropriate measures. Optionally, the second preset threshold can be manually set. It should be noted that the first database and the second database mentioned above can be the same database, distinguished and managed by different data tags. The first preset threshold and the second preset threshold can be set according to needs, and the first preset threshold and the second preset threshold can be the same.

[0091] Optionally, it can be determined whether data of IoT devices exists in the IoT system. If it is determined that the IoT system does not have data of IoT devices (e.g., vehicle identification numbers, part numbers, etc.), then the server will refuse to establish a communication connection with the IoT device. For example, when an IoT device (e.g., a vehicle) that has not completed registration and filing in the IoT system attempts to connect to the IoT, and the IoT system cannot find any data related to the IoT device, then the server will refuse to establish a communication connection with the IoT device.

[0092] Furthermore, the identification codes of IoT devices can be stored in a third database (e.g., Redis). When the number of IoT devices corresponding to an identification code in the third database is greater than or equal to a third preset threshold, the identification codes stored in the third database are exported and sent to relevant users (e.g., operations personnel) so that operations personnel can verify whether there are forged identification codes or unauthorized access. It should be noted that the first, second, and third databases can be set up independently, or they can be managed separately in the same database using different data tags. The first, second, and third preset thresholds can be configured separately according to requirements.

[0093] Optionally, determining that the IoT device communicates with the server through a unique connection channel includes: finding the channel used in the last connection based on the IoT device's device number (e.g., a unique device identifier or device ID), closing the previously used channel, and ensuring that the IoT device and the server communicate using a new channel. This avoids data interaction chaos or duplicate connection problems caused by historical connections not being properly released. For example, if an IoT device initiates multiple connection requests within a short period, the server can identify the IoT device's device number to find historical connection records, close historical channels, and ensure that each communication is based on a new, independent connection channel, improving the stability of data interaction.

[0094] In this embodiment, the IoT device and the server need to establish a connection through a two-way authentication algorithm of Transport Layer Security (TLS). For example, the IoT device (i.e., the client) sends a "Client hello" message to the server (i.e., the server). After receiving the "Client hello" message, the server replies with a "Server hello" message and sends its server certificate to the IoT device. The IoT device uses its public key to verify the validity of the server certificate. If the verification is successful, the IoT device generates a random number, encrypts it with the server's public key, and sends it to the server. The server uses its private key to decrypt the received pre-master key. The IoT device and the server generate a session key for symmetric encryption based on three random numbers (e.g., the IoT device's random number, the server's random number, and the pre-master key), completing the TLS handshake. After completing security authentication and establishing a communication connection, the IoT device and the server can interact with data based on the encrypted channel.

[0095] Optionally, the server can select one or more combinations of the above authentication methods to perform security authentication based on security level requirements. For example, in high-security scenarios (such as when vehicle control command transmission is involved), certificate validity verification, identification code consistency verification, and verification of the existence of device data in the IoT system can be enabled simultaneously; in normal-security scenarios (such as vehicle status information collection), only certificate validity verification can be enabled to achieve a dynamic balance between security and data transmission.

[0096] It should be noted that the above security authentication methods are merely examples, and those skilled in the art can add other security authentication dimensions according to actual application scenarios.

[0097] Step S620: Determine whether the security authentication has passed.

[0098] If the security authentication is successful, proceed to step S630 to establish a communication connection between the server and the IoT device. If the security authentication fails, prevent the establishment of a communication connection between the server and the IoT device, and return to step S610.

[0099] In this embodiment, security authentication is performed directly using the server. Compared to using a gateway plugin, this reduces an intermediate data transmission process, improves connection stability, and facilitates data security maintenance. Furthermore, the elimination of the need for an additional gateway plugin lowers costs, reduces operational complexity, and decreases dependence on external resources. Moreover, troubleshooting eliminates the need to check the gateway plugin, simplifying the process and improving the efficiency of problem detection and resolution.

[0100] Figure 7 This is a flowchart illustrating a data processing method provided in another embodiment of this application. This method is applied to message middleware in an Internet of Things (IoT) system, such as... Figure 7 As shown, the method includes the following steps.

[0101] Step S710: Receive target data sent by the server in the IoT system.

[0102] In some embodiments, the target data is based on the server. Figures 1 to 6 The method shown is used for sending, and will not be described again here. After receiving the target data, the message middleware can store or process the target data. In some embodiments, the message middleware includes multiple queues, and the target data can be forwarded to the corresponding queue according to the target routing rules.

[0103] In this embodiment, the server does not need to send data to the message middleware via a gateway plugin. Therefore, the server can flexibly select the most suitable message middleware for data forwarding and storage based on the characteristics (e.g., type) of the target data, improving data transmission efficiency. Furthermore, the server can dynamically generate new routing rules to adapt to the diverse data types generated by IoT devices, avoiding the limitations of fixed topics in traditional solutions. Additionally, it reduces the requirement for IoT devices (e.g., vehicles) to have classification capabilities, minimizing the risk of data transmission failures due to misclassification.

[0104] Figure 8 This is a flowchart illustrating a data processing method provided in another embodiment of this application. This method is applied to a load balancer in an Internet of Things (IoT) system, such as... Figure 8 As shown, the method includes the following steps.

[0105] Step S810: Receive target data from IoT devices.

[0106] In some embodiments, the load balancer communicates with IoT devices to receive target data sent by the IoT devices. In some embodiments, before receiving the target data, it may also receive connection requests from the IoT devices; according to the load balancing strategy, the connection requests are forwarded to the target server so that the target server executes the connection request. For example, after receiving the connection request, the target server performs security authentication; after confirming successful security authentication, it establishes a connection between the IoT device and the target server. Further details can be found in [reference needed]. Figure 6 The description in the text will not be repeated here.

[0107] Step S820: Forward the target data to the target server.

[0108] For example, target data is forwarded to a target server so that the target server determines a target routing rule matching the target data based on the target type of the target data, where the target type is determined by the fields of the target data; and routes the target data to the target message middleware according to the target routing rule. For more details, please refer to [link / reference]. Figures 2 to 5 The description in the text will not be repeated here.

[0109] In this embodiment, the load balancer determines the target server according to the load balancing strategy, which can avoid server overload and improve the overall performance and stability of the IoT system. The server does not need to send data to the message middleware through a gateway plugin; therefore, the server can flexibly select the most suitable message middleware for data forwarding and storage based on the characteristics (e.g., type) of the target data, improving data transmission efficiency. Furthermore, the server can dynamically generate new routing rules to adapt to the diverse data types generated by IoT devices, avoiding the limitations of fixed topics in traditional solutions. Additionally, it reduces the requirement for IoT devices (e.g., vehicles) to have classification capabilities, reducing the risk of data transmission failure due to misclassification.

[0110] Figure 9 This is a flowchart illustrating a data processing method according to another embodiment of this application. The method is applied to IoT devices in an IoT system and includes the following steps.

[0111] Step S910: Send target data to the target server of the IoT system.

[0112] In some embodiments, after sending target data to the target server of the Internet of Things system, the target server executes... Figures 1 to 6 The data processing method is illustrated. Optionally, before sending the target data, the IoT device sends a connection request to the target server to establish a communication connection with the target server. Both the target data and / or the connection request are forwarded to the target server through the load balancer of the IoT system.

[0113] In this embodiment, the server does not need to send data to the message middleware via a gateway plugin. Therefore, the server can flexibly select the most suitable message middleware for data forwarding and storage based on the characteristics (e.g., type) of the target data, improving data transmission efficiency. Furthermore, the server can dynamically generate new routing rules to adapt to the diverse data types generated by IoT devices, avoiding the limitations of fixed topics in traditional solutions. Additionally, it reduces the requirement for IoT devices (e.g., vehicles) to have classification capabilities, minimizing the risk of data transmission failures due to misclassification.

[0114] Figure 10 This is a schematic diagram of the structure of a vehicle networking system provided in one embodiment of this application. Figure 10 As shown, the Internet of Things (IoT) system includes an IoT device 1010, a load balancer 1020, at least one server 1030, and a message middleware 1040.

[0115] The IoT device 1010 is connected to the load balancer 1020, the load balancer 1020 is connected to each server 1030, and the server 1030 is connected to the message middleware 1040.

[0116] The Internet of Things (IoT) device 1010 is used to collect and transmit data. Optionally, the IoT device 1010 may include a vehicle, in-vehicle equipment, or other smart terminal.

[0117] Load balancer 1020 is configured to forward connection requests sent by IoT device 1010 to server 1030, and / or forward target data sent by IoT device 1010 to server 1030. In some embodiments, load balancer 1020 may determine a target server from at least one server 1030 according to a load balancing strategy. Optionally, the load balancing strategy may include at least one or any combination of round-robin, weighted, least connections, and response time-based allocation strategies. Upon receiving a connection request from IoT device 1010, load balancer 1020 may select a target server (e.g., a server with a lower current load) from at least one server 1030 according to the load balancing strategy and send the connection request to the target server, thereby enabling IoT device 1010 to establish a communication connection with the target server.

[0118] In an IoT system, the load balancer 1020 serves as a crucial intermediary node connecting IoT devices 1010 and servers 1030, undertaking the functions of traffic distribution and resource scheduling. For example, the load balancer 1020 needs to monitor the real-time operating status of each server 1030, including but not limited to any one or any combination of indicators such as the current number of connections, CPU utilization, memory usage, and network bandwidth usage, and dynamically adjust the load balancing strategy based on this. For instance, when using a round-robin strategy, the load balancer 1020 will distribute the connection requests from IoT devices 1010 to different servers 1030 in a preset order, ensuring a relatively balanced number of requests processed by each server 1030.

[0119] Optionally, there can be multiple IoT devices 1010. Multiple IoT devices 1010 can connect to the same server 1030 or to different servers 1030. This application does not limit the number of IoT devices 1010 or the number of servers 1030. Interaction between the IoT devices 1010 and the server 1030 can be achieved through the Message Queuing Telemetry Transport (MQTT) protocol. The MQTT protocol is a lightweight message transmission protocol designed based on a publish / subscribe model, suitable for environments with limited bandwidth and unstable networks. In this embodiment, the server 1030 includes an MQTT message broker.

[0120] In some embodiments, the target server (one of the servers 1030) is configured to: perform security authentication in response to a connection request from the IoT device 1010; and establish a communication connection between the target server and the IoT device 1010 if the security authentication is successful. Optionally, performing security authentication includes at least one of the following: verifying the validity of the IoT device's certificate; verifying the consistency between the IoT device's device identifier and the identification code in the certificate; determining whether the IoT device's data exists in the IoT system; and determining that the IoT device communicates with the server through a unique connection channel. For more details on performing security authentication, please refer to [link to relevant documentation]. Figure 6 This will not be elaborated upon here.

[0121] Optionally, after establishing a communication connection with IoT device 1010, the target server is further configured to: receive target data; and route the target data to a target message middleware (one of the message middleware 1040) according to a target routing rule based on the target type of the target data. The target data is associated with IoT device 1010; for example, the target data is received from IoT device 1010 by load balancer 1030 and sent based on a load balancing strategy. The target type is determined based on fields in the target data. For more details on routing and forwarding target data, please refer to [link to relevant documentation]. Figures 2 to 5 This will not be elaborated upon here.

[0122] In some embodiments, the target server can dynamically generate new routing rules based on the target type of the target data. For example, new routing rules can be generated by designing and coding the routing logic of the target server. This only requires configuration in the logic code of the target server, without relying on third-party plugins, further improving the flexibility and customization capabilities of data forwarding.

[0123] Optionally, the target server is also used to perform integrity verification on the target data, such as by using a verification algorithm or cyclic redundancy check code to verify the target data to ensure that the target data is not lost or tampered with during transmission.

[0124] In some embodiments, the message middleware 1040 includes Kafka, RabbitMQ, Redis, TimescaleDB, HTTP Server, etc. The type of message middleware 1040 can be determined according to the actual needs of the IoT system. Different message middleware 1040s differ in throughput, latency, reliability, and functional characteristics. Those skilled in the art can make a reasonable selection based on data volume, real-time requirements, and system complexity. For example, for high-throughput, low-latency real-time vehicle data transmission scenarios, Kafka can be preferred; if richer routing strategies and reliable message delivery mechanisms are required, RabbitMQ can be considered.

[0125] The target message middleware (one of the message middleware 1040) is configured to receive target data forwarded by the target server (one of the servers 1030). In some embodiments, the target message middleware includes multiple queues, and the target data can be routed to one of the queues in the target message middleware. For example, when the target data is real-time vehicle location information, it can be routed to the "Vehicle Location Data" queue of the target message middleware for subscription and consumption by the map service module or the fleet management module; if the target data is a fault diagnostic code, it can be routed to the "Vehicle Fault Alarm" queue for further processing by the fault analysis module.

[0126] In this embodiment, security authentication is performed directly using the server. Compared to using a gateway plugin, this reduces an intermediate data transmission process, improves connection stability, and facilitates data security maintenance. Furthermore, the elimination of the need for an additional gateway plugin lowers costs, reduces operational complexity, and decreases dependence on external resources. Moreover, troubleshooting eliminates the need to check the gateway plugin, simplifying the process and improving the efficiency of problem detection and resolution.

[0127] Furthermore, since the server does not need to send data to the message middleware through a gateway plugin, it can flexibly select the most suitable message middleware for data forwarding and storage based on the characteristics (e.g., type) of the target data. This avoids the timeliness issues caused by gateway forwarding and improves data transmission efficiency. Moreover, the server can dynamically generate new routing rules to adapt to the diverse data types generated by IoT devices, avoiding the limitations of fixed topics in traditional solutions. Additionally, it reduces the requirement for IoT devices (e.g., vehicles) to have classification capabilities, minimizing the risk of data transmission failures due to misclassification. Furthermore, the server simultaneously performs security authentication and data routing functions, achieving deep integration of authentication logic and data forwarding processing. This simplifies the architecture of the IoT system, reduces costs, and lowers the difficulty of troubleshooting during testing.

[0128] Figure 11 This is a structural block diagram of a data processing apparatus provided in one embodiment of this application. The data processing apparatus 1100 is applied to a server in an Internet of Things (IoT) system, such as... Figure 11 As shown, the data processing device 1100 includes a first receiving module 1110, a determining module 1120, and a routing module 1130.

[0129] The first receiving module 1110 is used to receive target data, which is associated with an IoT device.

[0130] The determination module 1120 is used to determine the target routing rules that match the target data based on the target type. The target type is determined according to the fields in the target data.

[0131] The routing module 1130 is used to route target data to the target message middleware according to the target routing rules.

[0132] The specific working principle and benefits of the data processing device provided in the embodiments of this application are similar to those of the data processing method provided in the embodiments of this application, and will not be repeated here.

[0133] Figure 12This is a schematic diagram of the structure of a data processing apparatus provided in another embodiment of this application. This data processing apparatus 1200 is applied to the message middleware of an Internet of Things (IoT) system, such as... Figure 12 As shown, the data processing device 1200 includes a second receiving module 1210 for receiving target data sent by a server in an Internet of Things (IoT) system, wherein the target data is based on... Figures 1 to 6 It was sent using the method shown.

[0134] The specific working principle and benefits of the data processing device provided in the embodiments of this application are similar to those of the data processing method provided in the embodiments of this application, and will not be repeated here.

[0135] Figure 13 This is a schematic diagram of the structure of a data processing device provided in another embodiment of this application. This data processing device 1300 is applied to a load balancer in an Internet of Things (IoT) system, such as... Figure 13 As shown, the data processing device 1300 includes a third receiving module 1310 and a forwarding module 1320.

[0136] The third receiving module 1310 is used to receive target data from IoT devices.

[0137] The forwarding module 1320 is used to forward target data to the target server so that the target server can determine the target routing rule matching the target data based on the target type of the target data, the target type being determined according to the fields in the target data; and route the target data to the target message middleware according to the target routing rule.

[0138] The specific working principle and benefits of the data processing device provided in the embodiments of this application are similar to those of the data processing method provided in the embodiments of this application, and will not be repeated here.

[0139] Figure 14 This is a schematic diagram of the structure of a data processing apparatus provided in another embodiment of this application. This data processing apparatus 1400 is applied to Internet of Things (IoT) devices in an IoT system, such as… Figure 14 As shown, the data processing device 1400 includes a sending module 1410 for sending target data to the target server of the Internet of Things system, so that the target server can perform... Figures 1 to 6 The method shown.

[0140] Below, for reference Figure 15 This describes an electronic device according to embodiments of the present application. Figure 15 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0141] like Figure 15 As shown, the electronic device 1500 includes one or more processors 1501 and memory 1502.

[0142] The processor 1501 may be a central processing unit (CPU) or other form of processing unit with data processing capabilities and / or instruction execution capabilities, and may control other components in the electronic device 1500 to perform desired functions.

[0143] The memory 1502 may include one or more computer program products, which may include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. The volatile memory may include, for example, random access memory (RAM) and / or cache memory. The non-volatile memory may include, for example, read-only memory (ROM), hard disk, flash memory, etc. One or more computer program instructions may be stored on the computer-readable storage medium, and the processor 1501 may execute the program instructions to implement the data processing methods and / or other desired functions of the various embodiments of this application described above. Various contents, such as connection requests and target data, may also be stored in the computer-readable storage medium.

[0144] In one example, the electronic device 1500 may also include an input device 1503 and an output device 1504, which are interconnected via a bus system and / or other forms of connection mechanism (not shown).

[0145] The input device 1503 may include, for example, a keyboard, a mouse, etc.

[0146] The output device 1504 can output various information to the outside, including target data. The output device 1504 may include, for example, a display, a speaker, a printer, and a communication network and its connected remote output devices, etc.

[0147] Of course, for the sake of simplicity, Figure 15 Only some of the components of the electronic device 1500 relevant to this application are shown in this illustration; components such as buses, input / output interfaces, etc., are omitted. In addition, the electronic device 1500 may include any other suitable components depending on the specific application.

[0148] In addition to the methods and apparatus described above, embodiments of this application may also be computer program products, which include computer program instructions that, when executed by a processor, cause the processor to perform the steps of the data processing methods according to various embodiments of this application as described above.

[0149] The computer program product can be written in any combination of one or more programming languages ​​to perform the operations of the embodiments of this application. The programming languages ​​include object-oriented programming languages ​​such as Java and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computing device, partially on the user's computing device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0150] Furthermore, embodiments of this application may also be computer-readable storage media storing computer program instructions thereon, which, when executed by a processor, cause the processor to perform the steps in the data processing methods according to various embodiments of this application described above.

[0151] The computer-readable storage medium may be any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof.

[0152] The basic principles of this application have been described above with reference to specific embodiments. However, it should be noted that the advantages, benefits, and effects mentioned in this application are merely examples and not limitations, and should not be considered as essential features of each embodiment of this application. Furthermore, the specific details disclosed above are for illustrative and facilitative purposes only, and are not limitations. These details do not limit the application to the necessity of employing the aforementioned specific details for implementation.

[0153] The block diagrams of devices, apparatuses, devices, and systems involved in this application are merely illustrative examples and are not intended to require or imply that they must be connected, arranged, or configured in the manner shown in the block diagrams. As those skilled in the art will recognize, these devices, apparatuses, devices, and systems can be connected, arranged, and configured in any manner. Words such as “comprising,” “including,” “having,” etc., are open-ended terms meaning “including but not limited to,” and are used interchangeably with them. The terms “or” and “and” as used herein refer to the terms “and / or,” and are used interchangeably with them unless the context clearly indicates otherwise. The term “such as” as used herein refers to the phrase “such as but not limited to,” and is used interchangeably with it.

[0154] It should also be noted that in the apparatus, equipment, and methods of this application, the components or steps can be disassembled and / or recombined. These disassemblies and / or recombinations should be considered as equivalent solutions of this application.

[0155] The above description of the disclosed aspects is provided to enable any person skilled in the art to make or use this application. Various modifications to these aspects will be readily apparent to those skilled in the art, and the general principles defined herein can be applied to other aspects without departing from the scope of this application. Therefore, this application is not intended to be limited to the aspects shown herein, but rather to be accorded the widest scope consistent with the principles and novel features disclosed herein.

[0156] The above description has been given for purposes of illustration and description. Furthermore, this description is not intended to limit the embodiments of this application to the forms disclosed herein. Although numerous exemplary aspects and embodiments have been discussed above, those skilled in the art will recognize certain variations, modifications, alterations, additions, and sub-combinations thereof.

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

Claims

1. A data processing method, characterized by, A server applied to an Internet of Things system, the method comprising: receiving target data associated with an Internet of Things device; determining a target routing rule matching the target data based on a target type of the target data, the target type being determined according to a field in the target data; routing the target data to a target message middleware according to the target routing rule.

2. The method of claim 1, wherein, The target data is received by a load balancer of the Internet of Things system from the Internet of Things device and sent based on a load balancing strategy.

3. The method of claim 1, wherein, The determining of the target routing rule matching the target data based on the target type of the target data comprises: obtaining a pre-configured routing rule set, the pre-configured routing rule set comprising a plurality of routing rules, each routing rule corresponding to at least one type; determining the target routing rule based on the target type and the pre-configured routing rule set.

4. The method of claim 3, wherein, The determining of the target routing rule based on the target type and the pre-configured routing rule set comprises: if there is no routing rule matching the target type in the pre-configured routing rule set, generating a new routing rule based on the target type and determining the new routing rule as the target routing rule.

5. The method of claim 1, wherein, Before the determining of the target routing rule matching the target data based on the target type of the target data, the method further comprises: analyzing the target data to obtain an analysis result; determining that the target data needs to be routed to the target message middleware based on the analysis result.

6. The method of claim 1, wherein, Before the receiving of the target data, the method further comprises: performing security authentication in response to a connection request from the Internet of Things device; if the security authentication is passed, establishing a communication connection between the server and the Internet of Things device.

7. The method of claim 6, wherein, The performing of the security authentication comprises at least one of the following: verifying validity of a certificate of the Internet of Things device; verifying consistency of a device identifier of the Internet of Things device with an identification code in the certificate; determining whether there is data of the Internet of Things device in the Internet of Things system; determining that the Internet of Things device is connected to the server through a unique connection channel.

8. A data processing method, characterized by, A message middleware applied to an Internet of Things system, the method comprising: receiving target data sent by a server in the Internet of Things system, wherein the target data is sent by the server based on the method of any one of claims 1 to 7.

9. A data processing method, characterized by, A load balancer applied to an Internet of Things system, the method comprising: receiving target data from an Internet of Things device; forwarding the target data to a target server, so that the target server determines a target routing rule matching the target data based on a target type of the target data, the target type being determined according to a field in the target data; and routes the target data to a target message middleware according to the target routing rule.

10. The method of claim 9, wherein, Before the receiving of the target data from the Internet of Things device, the method further comprises: receiving a connection request from the Internet of Things device; forwarding the connection request to the target server according to a load balancing strategy, so that the target server performs the connection request.

11. A data processing method, characterized by, An Internet of Things device applied to an Internet of Things system, the method comprising: sending target data to a target server of the Internet of Things system, so that the target server performs the method of any one of claims 1 to 7.

12. An Internet of Things system, characterized by comprising a server and at least one message middleware; the server is configured to: receive target data; route the target data to a target message middleware according to a target routing rule matched based on a target type of the target data; wherein the target data is associated with an Internet of Things device, and the target type is determined according to a field in the target data; the target message middleware is configured to: receive the target data forwarded by the server.

13. The Internet of Things system of claim 12, wherein, The Internet of Things system further comprises a load balancer, the load balancer is configured to: forward a connection request sent by the Internet of Things device to the server, and / or forward target data sent by the Internet of Things device to the server.

14. An electronic device, comprising: comprising: a processor; a memory connected with the processor, the memory being used to store a computer program, the computer program being executed by the processor to implement the method of any one of claims 1 to 11.

15. A storage medium, characterized by The storage medium has a computer program stored thereon, and the computer program is run by a processor to implement the method of any one of claims 1 to 11.

16. A computer program product, characterised in that, comprising computer program instructions, which, when executed by a processor, implement the method of any one of claims 1 to 11.

Images