Intelligent equipment unified access method and system based on cloud platform

Abstract

The invention provides an intelligent device unified access method and system based on a cloud platform, and relates to the technical field of cloud platforms, and the method comprises the steps: carrying out the validity verification of a terminal access request, and obtaining an authentication token of an intelligent device; performing grading adaptation on the terminal access request through the authority attribute of the authentication token and the service grade information of the value-added service of the intelligent equipment in the high-concurrency scene to obtain the access priority of the terminal access request; querying a protocol conversion rule of the intelligent equipment from a cache pool of the cloud platform, and when the protocol conversion rule does not exist, determining a time delay tolerance threshold value of protocol conversion of the intelligent equipment in the high-concurrency scene according to the access priority and the task load of cloud platform protocol conversion; and determining a protocol conversion strategy according to the time delay tolerance threshold, performing protocol conversion on a protocol request packet of the intelligent equipment, and caching a newly generated protocol conversion rule to a cache pool of the cloud platform. According to the invention, the protocol conversion speed of the intelligent equipment can be accelerated in a high-concurrency scene.

Description

Technical Field

[0001] This application relates to the field of cloud platform technology, and more specifically, to a unified access method and system for smart devices based on a cloud platform. Background Technology

[0002] With the rapid development of the Internet of Things and smart devices, cloud platforms are playing an increasingly prominent role as a crucial infrastructure for the unified management and scheduling of smart devices. Cloud platforms not only undertake data storage, computing, and analysis tasks, but also handle core functions such as device access, protocol parsing, and resource scheduling. Through centralized management, cloud platforms can achieve unified access and efficient scheduling of large-scale heterogeneous devices, support diverse value-added services, and provide stable and reliable basic support for application scenarios such as smart homes, industrial automation, and smart cities, thereby significantly improving the collaborative capabilities and service efficiency of smart devices.

[0003] In existing technologies, there are protocol differences between smart devices and cloud platforms, requiring protocol conversion to achieve interoperability. However, in high-concurrency scenarios, the number of device terminal access requests surges. Traditional protocol conversion mechanisms based on fixed rules or static mapping often struggle to cope with a large number of instantaneous requests, leading to low conversion efficiency, increased response latency, and even request backlog or conversion failures. Furthermore, existing technologies lack conversion strategies that dynamically adjust access priorities and task loads, making it difficult to achieve intelligent and efficient scheduling and caching optimization. These issues directly affect the real-time performance and scalability of the system, restricting the stable operation of smart devices in high-concurrency environments. Therefore, how to accelerate the protocol conversion speed of smart devices in high-concurrency scenarios has become a challenge for the industry. Summary of the Invention

[0004] This application provides a unified access method and system for smart devices based on a cloud platform, which can accelerate the protocol conversion speed of smart devices in high-concurrency scenarios.

[0005] Firstly, this application provides a unified access method for smart devices based on a cloud platform, the unified access method for smart devices including the following steps: The cloud platform receives terminal access requests initiated by smart devices in high-concurrency scenarios; The access authentication service of the cloud platform verifies the legitimacy of the terminal access request and obtains the authentication token of the smart device. Once authentication is successful, the terminal access request is hierarchically adapted based on the permission attributes of the authentication token and the service level information of the value-added services of the smart device in high-concurrency scenarios, so as to obtain the access priority of the terminal access request. The protocol conversion rules for smart devices are queried from the cache pool of the cloud platform. When the protocol conversion rules do not exist, the latency tolerance threshold for protocol conversion of smart devices in high-concurrency scenarios is determined based on the access priority and the workload of protocol conversion on the cloud platform. Based on the latency tolerance threshold, a protocol conversion strategy is determined. The protocol conversion of the smart device's protocol request packets is performed through the protocol conversion strategy and the semantic mapping relationship between the cloud platform protocol and the smart device protocol. The newly generated protocol conversion rules are then cached in the cloud platform's cache pool.

[0006] In this embodiment, the authentication token for the smart device is obtained by verifying the legitimacy of the terminal access request through the access authentication service of the cloud platform, specifically including: The cloud platform's access authentication service extracts the smart device's identification information, device key, and device certificate from the terminal's access request. The identification information is matched and verified against the device whitelist pre-stored in the cloud platform; If the device identifier verification passes, the device key is decrypted and verified using a preset encryption algorithm; Verify the validity period of the equipment certificate and the legitimacy of the issuing authority; Once the device identifier, key verification, and certificate verification all pass, an authentication token for the smart device is generated.

[0007] In this embodiment, the terminal access request is hierarchically adapted based on the permission attributes of the authentication token and the service level information of the value-added services of the smart device in high-concurrency scenarios, resulting in the following specific access priority for the terminal access request: The permission attributes in the authentication token are parsed to determine the types of cloud platform resources and operation permissions that the smart device can access. The terminal access request is classified into different levels of permissions based on the types of cloud platform resources that the smart device can access and the operation permissions, so as to obtain the resource access permission level of the terminal access request. Obtain the value-added service subscription information reported by the smart device, and extract the service level information of the value-added service of the smart device in high-concurrency scenarios from the value-added service subscription information; The service level of the terminal access request is obtained by classifying the service level information of the terminal access request. The access priority of the terminal access request is determined by the resource access permission level and the service level.

[0008] In this embodiment, querying the protocol conversion rules of smart devices from the cloud platform's cache pool specifically includes: Generate rule query keys based on the device type and protocol version information of the smart device; The rule query key is used to perform a matching query in the protocol rule index of the cloud platform cache pool; If the cache is hit, the protocol conversion rules corresponding to the smart device are obtained directly; If the cache is not hit, the protocol conversion rule generation process is triggered.

[0009] In this embodiment, determining the latency tolerance threshold for protocol conversion of smart devices in high-concurrency scenarios based on the access priority and the workload of cloud platform protocol conversion specifically includes: The latency benchmark value for protocol conversion of smart devices in high-concurrency scenarios is determined based on the access priority. Obtain the resource preemption coefficient of smart devices during protocol conversion in high-concurrency scenarios; Monitor the task load status of cloud platform protocol conversion, and extract the task volume of cloud platform protocol conversion from the task load status; The task latency index of the smart device during protocol conversion in a high-concurrency scenario is determined based on the task volume of the cloud platform protocol conversion and the resource preemption coefficient. The latency tolerance threshold for protocol conversion of intelligent devices in high-concurrency scenarios is determined based on the task latency index and the latency benchmark value.

[0010] In this embodiment, determining the protocol switching strategy based on the latency tolerance threshold specifically includes: The conversion granularity of protocol conversion for smart devices in high-concurrency scenarios is determined based on the latency tolerance threshold. The protocol conversion strategy is determined by the conversion granularity of protocol conversion in high-concurrency scenarios using smart devices.

[0011] In this embodiment, the protocol conversion of the protocol request packet of the smart device through the protocol conversion strategy and the semantic mapping relationship between the cloud platform protocol and the smart device protocol specifically includes: The protocol request packets of smart devices are semantically mapped by the protocol mapping table stored in the cloud platform, so as to obtain the semantic mapping relationship of protocol conversion between the cloud platform and smart devices. Determine the protocol conversion configuration information according to the protocol conversion strategy; The protocol conversion configuration information and the semantic mapping relationship are used to perform protocol conversion on the protocol request packets of the smart device.

[0012] In this embodiment, the access priority represents an evaluation index of the order in which terminal access requests are processed in a high-concurrency scenario.

[0013] In this embodiment, the latency tolerance threshold represents the maximum time limit that a smart device can tolerate during the protocol conversion process in a high-concurrency scenario.

[0014] Secondly, this application provides a unified access system for intelligent devices based on a cloud platform, used to execute a unified access method for intelligent devices based on a cloud platform, the unified access system for intelligent devices comprising: The request receiving module is used by the cloud platform to receive terminal access requests initiated by smart devices in high-concurrency scenarios. The legitimacy verification module is used to verify the legitimacy of the terminal access request through the access authentication service of the cloud platform and obtain the authentication token of the smart device. The hierarchical adaptation module is used to perform hierarchical adaptation on the terminal access request after successful authentication by using the permission attributes of the authentication token and the service level information of the value-added services of the smart device in high-concurrency scenarios, so as to obtain the access priority of the terminal access request. The conversion latency analysis module is used to query the protocol conversion rules of smart devices from the cache pool of the cloud platform. When the protocol conversion rules do not exist, the latency tolerance threshold of the smart device in the high-concurrency scenario is determined according to the access priority and the workload of protocol conversion on the cloud platform. The protocol conversion module is used to determine the protocol conversion strategy based on the latency tolerance threshold, convert the protocol request packets of the smart device through the protocol conversion strategy and the semantic mapping relationship between the cloud platform protocol and the smart device protocol, and then cache the newly generated protocol conversion rules in the cache pool of the cloud platform.

[0015] The technical solutions provided by the embodiments disclosed in this application have the following beneficial effects: In high-concurrency scenarios, the cloud platform receives terminal access requests initiated by smart devices. It verifies the legitimacy of these requests using its access authentication service to obtain an authentication token for the smart device. Upon successful authentication, the platform performs hierarchical adaptation of the terminal access request based on the authentication token's permission attributes and the smart device's service level information for value-added services in high-concurrency scenarios, thus determining the access priority of the request. The platform queries the cloud platform's cache pool for the smart device's protocol conversion rules. If no rules exist, it determines the latency tolerance threshold for protocol conversion in high-concurrency scenarios based on the access priority and the cloud platform's protocol conversion workload. A protocol conversion strategy is determined based on this threshold. The protocol conversion strategy, along with the semantic mapping between the cloud platform's protocol and the smart device's protocol, is used to convert the smart device's protocol request packets. The newly generated protocol conversion rules are then cached in the cloud platform's cache pool.

[0016] Therefore, this application demonstrates that the protocol conversion strategy and the semantic mapping relationship between the cloud platform protocol and the smart device protocol can be used to convert the protocol request packets of the smart device. Firstly, during the access phase, the cloud platform receives terminal access requests from the smart device in real time under high concurrency, and verifies the legitimacy of the requests using the access authentication service, generating an authentication token with permission attributes. This ensures access security and reliable identification of the device identity. Furthermore, the permission attributes of the authentication token and the service level information of the device's value-added services are used to hierarchically adapt the terminal access requests, obtaining access priorities. This allows the system to rationally prioritize and schedule resources for requests of different importance and business needs, preventing high-priority requests from being affected by delays. Simultaneously, it improves overall scheduling efficiency; secondly, during the protocol conversion phase, it queries the protocol conversion rules of smart devices through the cache pool to reuse the generated rules and reduce resource consumption caused by repeated calculations; when the rules do not exist, it dynamically determines the latency tolerance threshold based on the access priority and the cloud platform protocol conversion task volume, enabling the system to balance response speed and computing resource usage under instantaneous high load conditions, avoiding conversion task backlog or failure; thirdly, it implements protocol conversion based on the latency tolerance threshold and the semantic mapping relationship between the cloud platform and device protocols, which can accurately and quickly complete the format and semantic conversion of request packets, while caching the newly generated protocol conversion rules to the cloud platform cache pool to realize dynamic updating and reuse of rules, significantly improving protocol conversion efficiency and system throughput.

[0017] In summary, the technical solution adopted in this application can accelerate the protocol conversion speed of smart devices in high-concurrency scenarios. Attached Figure Description

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

[0019] Figure 1 This is an exemplary flowchart of a unified access method for smart devices based on a cloud platform provided in this application; Figure 2 This is a flowchart illustrating the process for determining access priority provided in this application; Figure 3 This is a flowchart illustrating the process for determining the latency tolerance threshold provided in this application; Figure 4 This is a module structure diagram of a unified access system for smart devices based on a cloud platform, provided in this application. Detailed Implementation

[0020] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0021] This application provides a unified access method and system for smart devices based on a cloud platform. The core of this method involves the cloud platform receiving terminal access requests initiated by smart devices in high-concurrency scenarios; verifying the legality of the terminal access requests through the cloud platform's access authentication service to obtain an authentication token for the smart device; upon successful authentication, classifying and adapting the terminal access requests according to the permission attributes of the authentication token and the service level information of the smart device's value-added services in high-concurrency scenarios to obtain the access priority of the terminal access requests; querying the protocol conversion rules of the smart devices from the cloud platform's cache pool; if no protocol conversion rules exist, determining the latency tolerance threshold for protocol conversion of the smart devices in high-concurrency scenarios based on the access priority and the cloud platform's protocol conversion workload; determining a protocol conversion strategy based on the latency tolerance threshold; and performing protocol conversion on the smart device's protocol request packets through the protocol conversion strategy and the semantic mapping relationship between the cloud platform protocol and the smart device protocol, thereby caching the newly generated protocol conversion rules in the cloud platform's cache pool.

[0022] Example 1: To better understand the above technical solution, the following will provide a detailed description of the technical solution in conjunction with the accompanying drawings and specific implementation methods. (Refer to...) Figure 1 As shown in the figure, this is an exemplary flowchart of a unified access method for smart devices based on a cloud platform according to this embodiment of the application. The unified access method for smart devices includes the following steps: In step S1, the cloud platform receives terminal access requests from smart devices in a high-concurrency scenario.

[0023] In specific implementation, under high-concurrency scenarios, the cloud platform receives terminal access requests from smart devices through a request queuing mechanism; the terminal access request represents a connection request initiated by the smart device to the cloud platform, aiming to obtain the right to access the cloud platform's value-added service resources.

[0024] In step S2, the access request of the terminal is validated through the access authentication service of the cloud platform to obtain the authentication token of the smart device.

[0025] In this embodiment, the authentication token for the terminal access request is obtained by verifying the legitimacy of the terminal access request through the access authentication service of the cloud platform, which can be achieved through the following steps: The cloud platform's access authentication service extracts the smart device's identification information, device key, and device certificate from the terminal's access request. The identification information is matched and verified against the device whitelist pre-stored in the cloud platform; If the device identifier verification passes, the device key is decrypted and verified using a preset encryption algorithm; Verify the validity period of the equipment certificate and the legitimacy of the issuing authority; Once the device identifier, key verification, and certificate verification all pass, an authentication token for the smart device is generated.

[0026] It should be noted that the authentication token described in this application represents an encrypted digital credential for information exchange between smart devices and cloud platforms.

[0027] In specific implementation, firstly, the access authentication service of the cloud platform is invoked. The access authentication service represents the core service of providing "identity verification" and "access authorization" for smart devices. The access authentication service extracts the identification information (e.g., the MAC address of the smart device), device key (e.g., an AES-256 encrypted symmetric key), and device certificate (e.g., an X.509 standard format digital certificate) of the smart device from the terminal access request. Then, the extracted identification information is precisely matched with the device whitelist pre-stored in the cloud platform database (stored in Redis, with the identifier as the index to achieve O(1) level query). If no match is found, it is directly determined to be an illegal request. If the identifier verification is successful, the master key stored in the cloud platform is used to decrypt and verify the device key - specifically using the AES-256-CBC mode. The system first verifies the device certificate by comparing the decrypted key with the original key hash value (calculated using the SHA-256 algorithm) pre-set at the device's factory to ensure the key has not been tampered with. Then, it performs chain verification on the device certificate: first, it parses the certificate validity period field to check if the current time is within the validity period; then, it verifies the certificate authority's digital signature (using the RSA-2048 algorithm to verify the consistency between the signature value and the certificate hash value) to confirm that the certificate was issued by a trusted certificate authority and has not been forged. Once all three verification steps are passed, an authentication token is generated using the JWT standard—the token header declares the use of the HS256 signature algorithm, the payload includes the device identifier, permission level, and a 2-hour validity period (to prevent long-term valid tokens from being stolen). Finally, the server's private key is used to sign the token, generating the final authentication token, which is then returned to the smart device.

[0028] In step S3, after successful authentication, the terminal access request is hierarchically adapted based on the permission attributes of the authentication token and the service level information of the value-added services of the smart device in high-concurrency scenarios, so as to obtain the access priority of the terminal access request.

[0029] Preferably, in this embodiment, the terminal access request is hierarchically adapted based on the permission attributes of the authentication token and the service level information of the value-added services of the smart device in high-concurrency scenarios, thereby obtaining the access priority of the terminal access request, with reference to... Figure 2 As shown in the figure, this is a schematic diagram of the process for determining access priority in some embodiments of this application. In this embodiment, determining access priority can be achieved by the following steps: In step S31, the permission attributes in the authentication token are parsed to determine the types of cloud platform resources and operation permissions that the smart device can access. In step S32, the terminal access request is classified according to the types of cloud platform resources accessible to the smart device and the operation permissions, so as to obtain the resource access permission level of the terminal access request. In step S33, the value-added service subscription information reported by the smart device is obtained, and the service level information of the value-added service of the smart device in high-concurrency scenarios is extracted from the value-added service subscription information. In step S34, the terminal access request is classified according to the service level information to obtain the service level of the terminal access request; In step S35, the access priority of the terminal access request is determined by the resource access permission level and the service level.

[0030] It should be noted that the permission attributes mentioned in this application represent permission fields that identify the types of cloud platform resources that smart devices can access and their operation permissions; the service level information represents a set of service quality parameters set by the cloud platform to achieve differentiated access control of value-added service content subscribed by smart devices; and the access priority represents an evaluation index for the order of processing terminal access requests in high-concurrency scenarios.

[0031] In specific implementation, firstly, the authentication token is decoded using a JWT parsing tool, and then the permission field is extracted from the authentication token. This obtained permission field is used as the permission attribute in the authentication token. The permission attribute in the authentication token is then mapped using the cloud platform's preset field mapping rules, thereby obtaining the cloud platform resource types and operation permissions accessible to the smart device. Specifically, the cloud platform resource types include: core resources, ordinary resources, and public resources; the operation permissions specifically include: read-only, read-write, management, and control. Secondly, the cloud platform resource types accessible to the smart device are divided into three different sensitivity levels: core resources correspond to level 3, ordinary resources to level 2, and public resources to level 1. The operation permissions accessible to the smart device are also divided into three different control levels: read-only to level 1, read-write to level 2, management to level 3, and control to level 4. The levels corresponding to the cloud platform resource types accessible to the smart device are used as resource access levels. Finally, the levels corresponding to the operation permissions accessible to the smart device are used as resource access levels. The access level is used as the permission access level. The product of the resource access level and the permission access level is used as the resource access permission level of the terminal access request. Then, the value-added service subscription information reported by the smart device is received through the HTTP interface. Then, a JSON parsing tool is used to filter out the field containing the service level identifier from the value-added service subscription information. At the same time, a timestamp verification tool is used to compare the expiration timestamp corresponding to the service level identifier field in the value-added service subscription information with the current system timestamp of the cloud platform. If it has not expired, the service level identifier is retained. The information composed of all the unexpired service level identifiers is used as the service level information of the value-added services of the smart device in high-concurrency scenarios. Next, a hash table query is used to convert all the service level identifiers in the service level information into corresponding numerical levels. Then, all the converted numerical levels are added together, and the sum is used as the service level of the terminal access request. Finally, the resource access permission level and the service level are multiplied together, and the result is used as the access priority of the terminal access request.

[0032] In step S4, the protocol conversion rules of the smart device are queried from the cache pool of the cloud platform. When the protocol conversion rules do not exist, the latency tolerance threshold of the smart device for protocol conversion in high-concurrency scenarios is determined based on the access priority and the workload of protocol conversion on the cloud platform.

[0033] In this embodiment, querying the protocol conversion rules of smart devices from the cloud platform's cache pool can be achieved through the following steps: Generate rule query keys based on the device type and protocol version information of the smart device; The rule query key is used to perform a matching query in the protocol rule index of the cloud platform cache pool; If the cache is hit, the protocol conversion rules corresponding to the smart device are obtained directly; If the cache is not hit, the protocol conversion rule generation process is triggered.

[0034] It should be noted that the protocol conversion rules described in this application represent a set of standardized rules used by the cloud platform to implement the mapping of formats, semantics, and fields between smart device protocols and platform internal protocols.

[0035] In practice, firstly, when a smart device connects, it reports its device type identifier (e.g., "TERM-PHONE" represents a mobile phone device) and protocol version information (HTTP / 2.0, encoded as "HTTP-20") to the cloud platform. A structured concatenation method of "device type + protocol version information" is used to concatenate the device type and protocol version information, and the resulting string is used as the rule query key. For example, if the smart device is a smartphone with a device type of "TERM-PHONE" and a protocol version of "HTTP-20", the generated rule query key would be "TERM-PHONE_HTTP-20". Secondly, the cloud platform cache pool uses the rule query key to match and query the protocol rule index. In practice, a distributed memory cache such as Redis can be used. Cluster organizes the index into hash tables or prefix trees to accelerate lookups and uses consistent hashing on keys for scalability. To further reduce query costs, a Bloom filter can be used before querying to determine if a rule might exist, thus avoiding a large number of unnecessary queries on cold data. When the cache is hit, the corresponding protocol conversion rule for the smart device is returned directly using primitives such as HGET. When the cache is missed, the rule generation process is triggered. First, a double check is performed using a distributed lock (such as Redlock based on Redis) to prevent herding behavior. Then, the protocol mapping table is searched in the persistence layer (such as a MySQL database) by device type and protocol version. If the mapping table exists, the specific protocol conversion rule is synthesized by the rule template engine using the mapping table and the protocol syntax template. The template engine can be implemented using a general string template. The board or DSL parser can use semantic matching algorithms for complex semantic mappings when necessary. For example, the device protocol description and cloud protocol specification can be encoded into vectors and the most matching mapping item can be retrieved using cosine similarity. Vectorization can be achieved by leveraging open-source embedding models and building vector indexes (such as Faiss) in the offline stage to accelerate online retrieval. The generated protocol conversion rules should be verified during the generation process (syntax parsing, unit test sample playback, verification and calculation) to ensure correctness. After verification, the protocol conversion rules should be written back to the cache pool and a reasonable expiration policy and version number should be set to support gray rollback and gradual updates. Key indicators should be recorded throughout the process and exposed to the cloud platform's monitoring system (cache hit rate, generation latency, lock wait time, etc.). In high-concurrency scenarios, rate limiting or queuing mechanisms should be used to protect the protocol conversion rule generation service.

[0036] Preferably, in this embodiment, the latency tolerance threshold for protocol conversion of the smart device in high-concurrency scenarios is determined based on the access priority and the workload of cloud platform protocol conversion, with reference to... Figure 3 As shown in the figure, this is a flowchart illustrating the process of determining the latency tolerance threshold in some embodiments of this application. In this embodiment, the latency tolerance threshold can be determined using the following steps: In step S41, the latency reference value for protocol conversion of the smart device in a high-concurrency scenario is determined according to the access priority; In step S42, the resource preemption coefficient of the smart device during protocol conversion in a high-concurrency scenario is obtained; In step S43, the task load status of cloud platform protocol conversion is monitored, and the task volume of cloud platform protocol conversion is extracted from the task load status. In step S44, the task latency index of the smart device during protocol conversion in a high-concurrency scenario is determined based on the task volume of cloud platform protocol conversion and the resource preemption coefficient. In step S45, the latency tolerance threshold for protocol conversion of the smart device in a high-concurrency scenario is determined based on the task latency index and the latency reference value.

[0037] It should be noted that the latency benchmark value mentioned in this application represents the reference value for protocol conversion response time preset by the cloud platform based on the access priority of the smart device; the resource preemption coefficient represents a quantitative parameter of the smart device's ability to occupy cloud platform computing resources relative to other devices in the protocol conversion task; the task latency index represents the latency of the smart device's protocol conversion task in a high-concurrency scenario; and the latency tolerance threshold represents the maximum time limit that the smart device can tolerate for response latency during the protocol conversion process in a high-concurrency scenario.

[0038] In specific implementation, firstly, a preset priority-baseline value mapping table is used (for example, access priority level 5 corresponds to a latency baseline value of 50ms, level 4 corresponds to a latency baseline value of 80ms, level 3 corresponds to a latency baseline value of 120ms, level 2 corresponds to a latency baseline value of 180ms, and level 1 corresponds to a latency baseline value of 250ms). The latency baseline value corresponding to the access priority is directly matched by querying a hash table. This priority-baseline value mapping table is preset based on device response data in historical high-concurrency scenarios to ensure that the baseline value meets the service requirements of devices with different priorities. Secondly, fixed coefficients are set according to device type and protocol complexity (for example, the resource preemption coefficient for HTTP / 2.0 protocol conversion in high-concurrency scenarios for smartphones is 1.2, and the resource preemption coefficient for RTSP protocol conversion in high-concurrency scenarios for smart cameras is 1.2). The resource preemption factor during the conversion is 1.5. This factor is stored in the device attribute configuration library of the cloud platform. Next, the Prometheus monitoring tool is used to monitor the task load status of the cloud platform's protocol conversion, counting the number of currently pending tasks and using this total number as the task volume for protocol conversion. Then, the task volume is multiplied by the resource preemption factor, and the resulting value is used as the task latency index for protocol conversion in high-concurrency scenarios. Finally, the task latency index is multiplied by the latency benchmark value, and the resulting value is added back to the latency benchmark value. This sum is used as the latency tolerance threshold for protocol conversion in high-concurrency scenarios.

[0039] In step S5, a protocol conversion strategy is determined based on the latency tolerance threshold. The protocol conversion strategy and the semantic mapping relationship between the cloud platform protocol and the smart device protocol are used to convert the protocol request packets of the smart device. The newly generated protocol conversion rules are then cached in the cache pool of the cloud platform.

[0040] In this embodiment, determining the protocol switching strategy based on the latency tolerance threshold can be achieved through the following steps: The conversion granularity of protocol conversion for smart devices in high-concurrency scenarios is determined based on the latency tolerance threshold. The protocol conversion strategy is determined by the conversion granularity of protocol conversion in high-concurrency scenarios using smart devices.

[0041] It should be noted that the conversion granularity mentioned in this application refers to a quantitative description of the level of detail in the processing of the original protocol data of the smart device during the conversion process between the smart device protocol and the internal protocol of the cloud platform; the protocol conversion strategy refers to the set of operation rules for the smart device when converting protocols in high-concurrency scenarios.

[0042] In practical implementation, firstly, the reciprocal of the latency tolerance threshold is used as the sensitivity. When the sensitivity is ≥0.02, it is determined to be "zero-loss granularity," and this "zero-loss granularity" is used as the conversion granularity for protocol conversion in high-concurrency scenarios for smart devices. This requires that the protocol conversion completely preserve all field structures (including nesting levels and field order) and data precision (e.g., retaining 6 decimal places for floating-point numbers), allowing no information loss. When the sensitivity is between 0.01 and 0.02, it is determined to be "controllable-loss granularity," and "zero-loss granularity" is used as the conversion granularity for protocol conversion in high-concurrency scenarios for smart devices. Granularity is determined by calculating the frequency of consecutive occurrences of fields using a sliding window algorithm (window size set to 5 fields). High-frequency fields with a frequency of ≥3 occurrences (e.g., device status, core data) are retained, while low-frequency temporary fields (e.g., single-time debugging information) are discarded. When the sensitivity is <0.01, it is determined to be "adaptive loss granularity." The conversion granularity of protocol conversion for intelligent devices in high-concurrency scenarios is then determined using a greedy algorithm (with "field processing time / information value" as the greedy index). This algorithm prioritizes retaining fields with low unit processing time and high value (e.g., sensor values) and discards fields that are complex to process and have low value. (For example, encrypted verification fields); Finally, if the protocol conversion granularity of the smart device in a high-concurrency scenario is "zero-loss granularity", then a dedicated protocol converter (such as the open-source tool mbusd for Modbus to JSON) is used for bit-level precise conversion, and CRC check is used to ensure data integrity. For example, the Modbus protocol register value 0x0064 is precisely converted to decimal 100 while retaining the register address information, and the conversion strategy used is used as the protocol conversion strategy; if the protocol conversion granularity of the smart device in a high-concurrency scenario is "controllable loss granularity", then... Use regular expressions to extract key-value pairs of high-frequency fields, quickly assemble them into a platform-compatible format using a lightweight JSON library, skip format validation for low-frequency fields, and use the conversion strategy as the protocol conversion strategy. If the conversion granularity of the protocol conversion in a high-concurrency scenario for smart devices is "adaptive loss granularity", then directly split the original protocol data according to a preset delimiter (such as a comma), extract only the first 3 key fields (such as device ID, data value, and timestamp), and achieve millisecond-level format conversion through pre-compiled conversion functions (such as C language macro definitions), and use the conversion strategy as the protocol conversion strategy.

[0043] In this embodiment, the protocol conversion of the protocol request packet of the smart device through the protocol conversion strategy and the semantic mapping relationship between the cloud platform protocol and the smart device protocol can be achieved by the following steps: The protocol request packets of smart devices are semantically mapped by the protocol mapping table stored in the cloud platform, so as to obtain the semantic mapping relationship of protocol conversion between the cloud platform and smart devices. Determine the protocol conversion configuration information according to the protocol conversion strategy; The protocol conversion configuration information and the semantic mapping relationship are used to perform protocol conversion on the protocol request packets of the smart device.

[0044] In practical implementation, firstly, the cloud platform uses a protocol parsing tool to parse the protocol request packets of the smart device into byte streams, extracting field names, data types, and original semantics (e.g., parsing the field "payload" from the MQTT protocol packet, which is a byte array and has the semantic meaning of "device-reported data"). Then, it calls the protocol mapping table stored on the cloud platform (the table structure includes fields such as "device protocol type," "device field name," "platform field name," "type mapping rule," and "semantic mapping description"). Through SQL queries (e.g., "SELECT platform field name, type mapping rule FROM protocol_mapping WHERE device protocol type='MQTT' AND device field name='payload'"), it obtains matching relationships, thereby generating a mapping table. This mapping table serves as the semantic mapping relationship for protocol conversion between the cloud platform and the smart device. Secondly, a rule engine (e.g., Drools) is used to convert the protocol conversion strategy into configuration information, and this configuration information is used as the protocol conversion configuration information. Finally, a protocol conversion framework (e.g., Spring) is used. The integration framework loads protocol conversion configuration information and semantic mapping relationships, and performs conversion on smart device protocol request packets: First, the request packet is split by the parsing component of the protocol conversion framework, and field names are replaced according to semantic mapping relationships (e.g., "payload" is replaced with "report_data"). The data format is converted according to type mapping rules (e.g., byte array to JSON). Then, details are processed according to configuration information. Under the zero-loss strategy, the validation component (e.g., Hibernate Validator) fully validates the fields. Under the controllable loss strategy, only high-frequency fields are validated. Under the adaptive loss strategy, key fields are directly extracted. Finally, the converted data is encapsulated into the cloud platform protocol format, and the encapsulated protocol is used as the newly generated protocol conversion rule.

[0045] In practice, caching newly generated protocol conversion rules in the cloud platform's cache pool can be achieved in the following way: First, generate a unique identifier for the newly generated protocol conversion rule to ensure the uniqueness of the cache key; second, serialize the protocol conversion rule content into a JSON string (e.g., using the writeValueAsString method of the Jackson library) for easy storage and retrieval; next, call the Redis SET command (e.g., "SET rule:12345 '{"fields":...}'EX 3600") to set the cache expiration time (e.g., 1 hour) to prevent rules from being invalid for a long time and occupying resources; finally, record the cache operation log (including the protocol conversion rule ID, cache time, and expiration time) to the cloud platform's log system (e.g., ELK) for easy traceability and updates; if the cache pool space is insufficient, trigger the LRU (Least Recently Used) eviction policy to prioritize deleting rules that have not been accessed for a long time, ensuring the cache availability of core rules.

[0046] Therefore, this application demonstrates that the protocol conversion strategy and the semantic mapping relationship between the cloud platform protocol and the smart device protocol can be used to convert the protocol request packets of the smart device. Firstly, during the access phase, the cloud platform receives terminal access requests from the smart device in real time under high concurrency, and verifies the legitimacy of the requests using the access authentication service, generating an authentication token with permission attributes. This ensures access security and reliable identification of the device identity. Furthermore, the permission attributes of the authentication token and the service level information of the device's value-added services are used to hierarchically adapt the terminal access requests, obtaining access priorities. This allows the system to rationally prioritize and schedule resources for requests of different importance and business needs, preventing high-priority requests from being affected by delays. Simultaneously, it improves overall scheduling efficiency; secondly, during the protocol conversion phase, it queries the protocol conversion rules of smart devices through the cache pool to reuse the generated rules and reduce resource consumption caused by repeated calculations; when the rules do not exist, it dynamically determines the latency tolerance threshold based on the access priority and the cloud platform protocol conversion task volume, enabling the system to balance response speed and computing resource usage under instantaneous high load conditions, avoiding conversion task backlog or failure; thirdly, it implements protocol conversion based on the latency tolerance threshold and the semantic mapping relationship between the cloud platform and device protocols, which can accurately and quickly complete the format and semantic conversion of request packets, while caching the newly generated protocol conversion rules to the cloud platform cache pool to realize dynamic updating and reuse of rules, significantly improving protocol conversion efficiency and system throughput.

[0047] In summary, the technical solution adopted in this application can accelerate the protocol conversion speed of smart devices in high-concurrency scenarios.

[0048] Example 2: This application provides a unified access system for smart devices based on a cloud platform, referencing... Figure 4 As shown in the figure, this is a modular structure diagram of a unified access system for intelligent devices based on a cloud platform according to this embodiment of the present application. The unified access system for intelligent devices includes: The request receiving module 100 is used by the cloud platform to receive terminal access requests initiated by smart devices in high-concurrency scenarios. The legitimacy verification module 200 is used to verify the legitimacy of the terminal access request through the access authentication service of the cloud platform and obtain the authentication token of the smart device. The hierarchical adaptation module 300 is used to perform hierarchical adaptation on the terminal access request after successful authentication by using the permission attributes of the authentication token and the service level information of the value-added services of the smart device in high-concurrency scenarios, so as to obtain the access priority of the terminal access request. The conversion latency analysis module 400 is used to query the protocol conversion rules of the smart device from the cache pool of the cloud platform. When the protocol conversion rules do not exist, the latency tolerance threshold of the smart device in the high-concurrency scenario is determined according to the access priority and the workload of protocol conversion of the cloud platform. The protocol conversion module 500 is used to determine a protocol conversion strategy based on the latency tolerance threshold, convert the protocol request packets of the smart device through the protocol conversion strategy and the semantic mapping relationship between the cloud platform protocol and the smart device protocol, and then cache the newly generated protocol conversion rules in the cache pool of the cloud platform.

[0049] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0050] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, including read-only memory (ROM), random access memory (RAM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), one-time programmable read-only memory (OTPROM), electrically-Erasable Programmable Read-Only Memory (EEPROM), compactdisc read-only memory (CD-ROM) or other optical disc storage, disk storage, magnetic tape storage, or any other computer-readable medium capable of carrying or storing data.

[0051] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

Claims

1. A unified access method for intelligent devices based on a cloud platform, characterized in that, The unified access method for smart devices includes the following steps: The cloud platform receives terminal access requests initiated by smart devices in high-concurrency scenarios; The access authentication service of the cloud platform verifies the legitimacy of the terminal access request and obtains the authentication token of the smart device. Once authentication is successful, the terminal access request is hierarchically adapted based on the permission attributes of the authentication token and the service level information of the value-added services of the smart device in high-concurrency scenarios, so as to obtain the access priority of the terminal access request. The protocol conversion rules for smart devices are queried from the cache pool of the cloud platform. When the protocol conversion rules do not exist, the latency tolerance threshold for protocol conversion of smart devices in high-concurrency scenarios is determined based on the access priority and the workload of protocol conversion on the cloud platform. Based on the latency tolerance threshold, a protocol conversion strategy is determined. The protocol conversion of the smart device's protocol request packets is performed through the protocol conversion strategy and the semantic mapping relationship between the cloud platform protocol and the smart device protocol. The newly generated protocol conversion rules are then cached in the cloud platform's cache pool.

2. The unified access method for intelligent devices based on a cloud platform as described in claim 1, characterized in that, The authentication token for the smart device is obtained by verifying the legitimacy of the terminal access request through the access authentication service of the cloud platform, specifically including: The cloud platform's access authentication service extracts the smart device's identification information, device key, and device certificate from the terminal's access request. The identification information is matched and verified against the device whitelist pre-stored in the cloud platform; If the device identifier verification passes, the device key is decrypted and verified using a preset encryption algorithm; Verify the validity period of the equipment certificate and the legitimacy of the issuing authority; Once the device identifier, key verification, and certificate verification all pass, an authentication token for the smart device is generated.

3. The unified access method for intelligent devices based on a cloud platform as described in claim 1, characterized in that, The terminal access request is hierarchically adapted based on the permission attributes of the authentication token and the service level information of the value-added services of the smart device in high-concurrency scenarios. The specific access priority of the terminal access request includes: The permission attributes in the authentication token are parsed to determine the types of cloud platform resources and operation permissions that the smart device can access. The terminal access request is classified into different levels of permissions based on the types of cloud platform resources that the smart device can access and the operation permissions, so as to obtain the resource access permission level of the terminal access request. Obtain the value-added service subscription information reported by the smart device, and extract the service level information of the value-added service of the smart device in high-concurrency scenarios from the value-added service subscription information; The service level of the terminal access request is obtained by classifying the service level information of the terminal access request. The access priority of the terminal access request is determined by the resource access permission level and the service level.

4. The unified access method for intelligent devices based on a cloud platform as described in claim 1, characterized in that, Specifically, retrieving protocol conversion rules for smart devices from the cloud platform's cache pool includes: Generate rule query keys based on the device type and protocol version information of the smart device; The rule query key is used to perform a matching query in the protocol rule index of the cloud platform cache pool; If the cache is hit, the protocol conversion rules corresponding to the smart device are obtained directly; If the cache is not hit, the protocol conversion rule generation process is triggered.

5. The unified access method for intelligent devices based on a cloud platform as described in claim 1, characterized in that, The latency tolerance threshold for protocol conversion of smart devices in high-concurrency scenarios, determined based on the access priority and the workload of cloud platform protocol conversion, specifically includes: The latency benchmark value for protocol conversion of smart devices in high-concurrency scenarios is determined based on the access priority. Obtain the resource preemption coefficient of smart devices during protocol conversion in high-concurrency scenarios; Monitor the task load status of cloud platform protocol conversion, and extract the task volume of cloud platform protocol conversion from the task load status; The task latency index of the smart device during protocol conversion in a high-concurrency scenario is determined based on the task volume of the cloud platform protocol conversion and the resource preemption coefficient. The latency tolerance threshold for protocol conversion of intelligent devices in high-concurrency scenarios is determined based on the task latency index and the latency benchmark value.

6. The unified access method for intelligent devices based on a cloud platform as described in claim 1, characterized in that, Determining the protocol switching strategy based on the aforementioned latency tolerance threshold specifically includes: The conversion granularity of protocol conversion for smart devices in high-concurrency scenarios is determined based on the latency tolerance threshold. The protocol conversion strategy is determined by the conversion granularity of protocol conversion in high-concurrency scenarios using smart devices.

7. The unified access method for intelligent devices based on a cloud platform as described in claim 1, characterized in that, The protocol conversion of the protocol request packet of the smart device through the aforementioned protocol conversion strategy and the semantic mapping relationship between the cloud platform protocol and the smart device protocol specifically includes: The protocol request packets of smart devices are semantically mapped by the protocol mapping table stored in the cloud platform, so as to obtain the semantic mapping relationship of protocol conversion between the cloud platform and smart devices. Determine the protocol conversion configuration information according to the protocol conversion strategy; The protocol conversion configuration information and the semantic mapping relationship are used to perform protocol conversion on the protocol request packets of the smart device.

8. The unified access method for intelligent devices based on a cloud platform as described in claim 1, characterized in that, The access priority refers to an evaluation metric for the order in which terminal access requests are processed in high-concurrency scenarios.

9. The unified access method for intelligent devices based on a cloud platform as described in claim 1, characterized in that, The latency tolerance threshold represents the maximum time limit that a smart device can tolerate during the protocol conversion process in a high-concurrency scenario.

10. A unified access system for intelligent devices based on a cloud platform, used to execute a unified access method for intelligent devices based on a cloud platform as described in any one of claims 1 to 9, characterized in that, The unified access system for intelligent devices includes: The request receiving module is used by the cloud platform to receive terminal access requests initiated by smart devices in high-concurrency scenarios. The legitimacy verification module is used to verify the legitimacy of the terminal access request through the access authentication service of the cloud platform and obtain the authentication token of the smart device. The hierarchical adaptation module is used to perform hierarchical adaptation on the terminal access request after successful authentication by using the permission attributes of the authentication token and the service level information of the value-added services of the smart device in high-concurrency scenarios, so as to obtain the access priority of the terminal access request. The conversion latency analysis module is used to query the protocol conversion rules of smart devices from the cache pool of the cloud platform. When the protocol conversion rules do not exist, the latency tolerance threshold of the smart device in the high-concurrency scenario is determined according to the access priority and the workload of protocol conversion on the cloud platform. The protocol conversion module is used to determine the protocol conversion strategy based on the latency tolerance threshold, convert the protocol request packets of the smart device through the protocol conversion strategy and the semantic mapping relationship between the cloud platform protocol and the smart device protocol, and then cache the newly generated protocol conversion rules in the cache pool of the cloud platform.

Images