Unified access management method and equipment for multi-platform Internet of Things equipment, and storage medium

Abstract

The invention discloses a multi-platform Internet of Things equipment unified access management method, equipment and a storage medium, and relates to the technical field of Internet of Things integration. The method comprises the step of solving the fragmentation problem of cross-platform equipment access through dynamic configuration adaptation. The method comprises the following steps: starting from receiving a front-end equipment operation request, indexing a pre-configured mapping relation database through an equipment unique identifier, and obtaining a target platform type, an API address and an encryption certificate; dynamically calling a protocol adapter based on a platform type, and injecting an account certificate into a request header or a message body according to a platform specification; converting the original parameters into a format supported by a target platform through a protocol conversion engine, and combining the original parameters with the authentication information to generate a complete request; and realizing high-reliability communication by using an asynchronous message queue, and finally returning a platform response to a front end. According to the invention, through mapping management of the configuration driver and dynamic adapter scheduling, equipment access unification across the Internet of Things platform is realized.

Description

Technical Field

[0001] This application relates to the field of Internet of Things integration technology, and in particular to a unified access management method, device and storage medium for multi-platform Internet of Things devices. Background Art

[0002] With the rapid development of Internet of Things technology, the scenarios of intelligent device access have become increasingly complex. Devices from different manufacturers need to achieve data interaction and control instruction transmission through heterogeneous Internet of Things platforms. However, the deep customization differences in communication protocols, authentication mechanisms, and interface specifications among various platforms have led to serious fragmentation problems in cross-platform device access. The current mainstream solutions require developers to separately develop docking modules for each target platform, forming a "point-to-point" hard connection architecture between the device and the platform. This not only causes duplicate construction of the system but also brings interface compatibility risks due to platform version iterations, forcing front-end applications to perceive the differences in underlying platforms, resulting in fragmented user experiences and increased maintenance costs.

[0003] In the prior art, the docking between devices and Internet of Things platforms mostly adopts static coding methods to achieve protocol conversion and authentication adaptation. When a new device type is added or a new platform is accessed, it is necessary to re-develop adaptation codes and deploy independent service instances, resulting in low utilization rate of system resources and limited scalability. At the same time, multi-platform account keys are stored separately in different configuration files or databases, lacking a unified credential lifecycle management mechanism, which is prone to key leakage risks. Especially in a multi-tenant scenario, historical redundant accounts and expired keys cannot be cleared in a timely manner, further exacerbating permission management chaos and affecting system security.

[0004] Furthermore, the significant differences in the data format returned by heterogeneous platforms significantly increase the processing complexity of upper-layer applications. Existing solutions usually perform data format conversion at the front-end or business layer, resulting in strong coupling between core business logic and platform protocols. In addition, the traditional synchronous blocking request mechanism is prone to cause a system-level avalanche effect when facing high-concurrency device access because it cannot effectively isolate the response latency differences of different platforms. Such problems are particularly prominent in multi-platform hybrid deployment scenarios, severely restricting the large-scale application ability of Internet of Things systems.

[0005] Therefore, how to build a configuration-driven unified access method for Internet of Things devices to achieve cross-platform protocol dynamic adaptation, centralized management of account credentials, and automatic standardization conversion of heterogeneous data, while ensuring system stability in high-concurrency scenarios, has become a technical problem that needs to be urgently solved by those skilled in the art. Summary of the Invention

[0006] The embodiments of the present application provide a unified access management method, device, and storage medium for multi-platform Internet of Things devices, which are used to solve the following technical problems: how to achieve cross-platform protocol dynamic adaptation, centralized management of account credentials, and automatic standardization conversion of heterogeneous data, while ensuring system stability in high-concurrency scenarios.

[0007] In a first aspect, the embodiments of the present application provide a unified access management method for multi-platform Internet of Things devices, characterized in that the method includes: receiving a device operation request from a front-end application and extracting the device unique identifier carried in the device operation request; obtaining the corresponding mapping relationship information from a pre-configured mapping relationship database according to the device unique identifier; wherein the mapping relationship information includes: the target Internet of Things platform type, the platform API interface address, and the account authentication credentials; based on the target Internet of Things platform type, calling the corresponding protocol adapter from the dynamic adapter registry to dynamically write the account authentication credentials into the request header or message body of the request to be sent in the protocol format supported by the target Internet of Things platform through the credential processing module of the protocol adapter; converting the data query parameters in the device operation request into the protocol format supported by the target Internet of Things platform according to the platform API interface address, and merging the converted data query parameters with the request header or message body of the request to be sent to generate a request to be sent; sending the request to be sent to the target Internet of Things platform through an asynchronous message queue and listening for the response data returned by the platform; after the response data is monitored, returning the response data to the front-end application.

[0008] In an implementation manner of the present application, the method further includes: configuring the mapping relationship database, specifically including: receiving a device identifier entry operation in a visual configuration interface to generate a device registration record; associating at least one Internet of Things platform type and the corresponding account permission group with the device registration record; encrypting and storing the account authentication credentials through a key management service, and establishing an index relationship between the device identifier and the encrypted credentials.

[0009] In an implementation manner of the present application, the method further includes: constructing a dynamic adapter registry, specifically including: scanning the annotation identifiers of predefined adapter implementation classes in the system initialization stage; instantiating the scanned adapter classes and registering them in a memory hash table; wherein the key of the hash table is the platform type code, and the value is the reference pointer of the adapter instance.

[0010] In one implementation of the present application, through the credential processing module of the protocol adapter, the account authentication credential is dynamically written into the request header or message body of the request to be sent in the protocol format supported by the target IoT platform, specifically including: when the protocol corresponding to the protocol adapter is the HTTP protocol, writing the account authentication credential into the Authorization field of the request header to be sent; when the protocol corresponding to the protocol adapter is the MQTT protocol, writing the account authentication credential into the auth field of the request message body to be sent; for platforms that require dynamic signature, calling the signature algorithm of the adapter to generate a time-limited credential and write it in.

[0011] In one implementation of the present application, according to the platform API interface address, the data query parameters in the device operation request are converted into the protocol format supported by the target IoT platform, specifically including: parsing the list of required parameters defined in the target IoT platform API document to generate a parameter mapping template; performing key name replacement and type coercion on the original parameters in the device operation request according to the mapping template; packaging the converted parameters into HTTP REST, MQTT, or CoAP message packets according to the transport protocol type supported by the target IoT platform.

[0012] In one implementation of the present application, before sending the request to be sent to the target IoT platform through the asynchronous message queue, the method further includes: creating independent message channels for each target IoT platform type and configuring differentiated retry policies and timeout thresholds; configuring the sending logic to record the request sending timestamp and the platform response status code in the message persistent storage; configuring the sending exception handling logic to trigger the adaptive retransmission mechanism according to the retry policy when detecting that the platform response times out.

[0013] In one implementation of the present application, before returning the response data to the front-end application, the method further includes: extracting the business valid fields in the platform response data and filtering the platform internal status codes and debugging information; uniformly converting the heterogeneous data units into the international standard unit system; performing cross-platform semantic mapping on the enumerated fields to generate a standardized device status description.

[0014] In one implementation of the present application, the method further includes: regularly scanning the last usage timestamp of each account in the mapping relationship database; generating an alarm event for accounts that exceed the preset idle period and pushing the alarm information to the management terminal; receiving the account freezing instruction from the management terminal, updating the status flag of the corresponding account in the mapping relationship database to disabled, and terminating the subsequent device operation requests initiated through this account.

[0015] In the second aspect, an embodiment of the present application also provides a unified access management device for multi-platform Internet of Things devices, the device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute a unified access management method for multi-platform Internet of Things devices such as any one of the above items.

[0016] On the third aspect, an embodiment of the present application also provides a non-volatile computer storage medium for unified access management of multi-platform Internet of Things devices, which stores computer executable instructions. When the computer executable instructions are executed, a method for unified access management of multi-platform Internet of Things devices such as any of the above items is implemented.

[0017] The embodiments of the present application provide a method, device and storage medium for unified access management of multi-platform IoT devices, which have the following beneficial effects: The unified access management method and system for multi-platform IoT devices provided by the present invention have made significant breakthroughs in cross-platform compatibility, system scalability and operation and maintenance efficiency through innovative dynamic adaptation architecture and configurable mapping mechanism. By establishing a configurable mapping relationship between device-platform-account, the unified encapsulation of the protocol abstraction layer of heterogeneous IoT platforms is realized for the first time, so that when adding new devices or platforms, there is no need to modify the core business code, and only the adapter needs to be expanded and the configuration updated to complete the docking, shortening the adaptation cycle in the traditional hard-coded development mode from weeks to hours, greatly reducing the integration cost in multi-platform collaboration scenarios.

[0018] Based on the collaborative design of dynamic credential injection and asynchronous message queue, the problem of multi-platform request blocking in high-concurrency scenarios is effectively solved. By preloading protocol adapter instances and distributed caching mechanisms, time-consuming operations such as platform authentication and protocol conversion in the request processing link are optimized to millisecond-level responses. At the same time, asynchronous message channels are used to isolate the response delay differences of different platforms, avoiding the system-level avalanche effect caused by a single platform failure, and significantly improving system availability.

[0019] At the data governance level, the original standardized cleaning rule engine realizes the automatic alignment of heterogeneous data across platforms. Through semantic mapping and unified unit conversion, the data parsing ambiguity caused by platform private fields is eliminated, so that upper-level applications can consume standardized device data without perceiving the differences in the underlying platforms, and the coupling degree between business codes and platform protocols is greatly reduced. In addition, combined with the automatic cleaning mechanism of redundant accounts, through scheduled scanning and status linkage strategies, the risk of key leakage caused by the accumulation of historical accounts is eradicated, and the system security compliance reaches financial-level management and control standards. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings: Figure 1 A flow chart of a unified access management method for multi-platform IoT devices provided in an embodiment of the present application; Figure 2 A schematic diagram of the internal structure of a multi-platform IoT device unified access management device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0021] In order to make the purpose, technical solution and advantages of the present application clearer, the technical solution of the present application will be clearly and completely described below in combination with the specific embodiments of the present application and the corresponding drawings. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present application.

[0022] The embodiments of the present application provide a unified access management method, device and storage medium for multi-platform IoT devices, which are used to solve the following technical problems: how to achieve dynamic adaptation of cross-platform protocols, centralized management of account credentials and automatic standardized conversion of heterogeneous data, while ensuring system stability in high-concurrency scenarios.

[0023] The technical solution proposed in the embodiments of the present application is described in detail below with reference to the accompanying drawings.

[0024] Figure 1 A flow chart of a unified access management method for multi-platform IoT devices provided in an embodiment of the present application. Figure 1 As shown, a method for unified access management of multi-platform IoT devices provided in an embodiment of the present application specifically includes the following steps: Step 101: Receive a device operation request from a front-end application, and extract a device unique identifier carried in the device operation request.

[0025] In this embodiment, the front-end application initiates a device operation request to the system through a standardized API gateway, and the request type includes device data query, control instruction issuance, or status subscription, etc. For example, the front-end application can send a POST request to the / api / device / operation interface based on the HTTP protocol, and the request body contains a payload in JSON format, for example: { "deviceId": "HW-THERM-001", "operation": "readTemperature"} It is understandable that the device unique identifier (deviceId) needs to meet the global uniqueness rule, and is usually generated by combining the device manufacturer code, device type, and serial number. For example, the identifier can adopt a three - part structure "manufacturer code - device type - serial number" (such as "HW - THERM - 001" representing the 001st device of the thermal sensor of Huawei), or follow the device fingerprint defined by the International Organization for Standardization (such as the 64 - bit unique address in the IEEE EUI - 64 format).

[0026] Specifically, the system extracts the device unique identifier by parsing specific fields in the request message. For RESTful API requests, the identifier can be extracted from the URL path parameters (such as "D001" in / api / device / D001 / control); for MQTT protocol requests, it is obtained from the hierarchical structure of the message topic (such as the second level of device / D001 / control). It should be noted that during the extraction process, format legality verification needs to be performed on the identifier. For example, it is verified whether it conforms to the predefined encoding rule through a regular expression (such as ^[A - Z]{2}-[A - Z]{5}-\d{3}$). If the verification fails, an error response is immediately returned to block the subsequent process.

[0027] Exemplarily, when the system detects an abnormal device identifier format, the following error response is generated: { "code": 400, "message": "Invalid deviceId format" } This design can effectively intercept illegal requests, avoid invalid database queries or adapter loading operations caused by incorrect identifiers, thereby improving the robustness of the system.

[0028] It is understandable that the extraction of the device unique identifier is the basis for all subsequent operations. Through this identifier, the system can uniquely determine the type of Internet of Things platform, interface address, and account credentials associated with the target device (the configuration logic of the mapping relationship database in Association Right 2), thereby providing necessary input for cross - platform protocol adaptation. For example, when the device identifier is "ALI - LIGHT - 005", the system will query based on this identifier that the device needs to access the Alibaba Cloud intelligent lighting platform and trigger the corresponding adaptation logic.

[0029] It should be noted that the "front-end application" mentioned in this step is not limited to the client directly operated by the user, but also includes other business systems, third-party services or automation scripts. The request initiation methods can cover various communication protocols such as HTTP / HTTPS, MQTT, WebSocket, etc. The system uniformly processes them through the protocol parsing and adaptation layer to ensure the compatibility of heterogeneous request sources.

[0030] Step 102: Obtain the corresponding mapping relationship information from the pre-configured mapping relationship database according to the device unique identifier.

[0031] First of all, it should be noted that the mapping relationship information in this embodiment includes: the target Internet of Things platform type, the platform API interface address, and the account authentication credential.

[0032] In this embodiment, the mapping relationship database is designed with a distributed key-value storage architecture, and a two-level storage structure of a cache layer and a persistence layer is implemented based on RedisCluster. Exemplarily, the device unique identifier is used as the primary key (Key), and its corresponding value (Value) is stored in JSON object format, including the following core fields: { "platformType": "HW_IOT", "apiEndpoint": "https: / / iot.huaweicloud.com:443 / v5 / iotda / region", "encryptedCredential": "U2FsdGVkX1+3C7Zq...", "accountGroup": "PROD_GROUP_02" } It can be understood that the target Internet of Things platform type (platformType) adopts a standardized coding system. For example, "HW_IOT" represents the Huawei Cloud Internet of Things platform, and "ALI_LINK" represents the Alibaba Cloud Internet of Things platform. The platform API interface address (apiEndpoint) includes the protocol type (HTTP / HTTPS / MQTT), the domain name, and the API version path to ensure that requests are accurately routed to the service nodes of the target platform.

[0033] It is understandable that the target Internet of Things (IoT) platform type (platformType) adopts a standardized coding system. For example, "HW_IOT" represents the Huawei Cloud IoT platform, and "ALI_LINK" represents the Alibaba Cloud IoT platform. The platform API interface address (apiEndpoint) includes the protocol type (HTTP / HTTPS / MQTT), domain name, and API version path to ensure that requests are accurately routed to the service nodes of the target platform.

[0034] Specifically, the system completes the mapping relationship query through the following steps: 1. Cache priority query: First, query the mapping relationship corresponding to the device identifier from the Redis cache. If the cache hits and the data has not expired (controlled by the TTL mechanism), directly return the decrypted account authentication credential. 2. Persistent layer backhaul: When the cache misses, trigger the distributed lock mechanism to prevent cache breakdown in high-concurrency scenarios. The system queries the device registry (device_registry) from the MySQL sharding database and obtains the original data according to the device-platform-account index relationship established in claim 2. 3. Credential decryption processing: Decrypt the encrypted account authentication credential through the key management service (KMS) (corresponding to the key management service in claim 2). Exemplarily, the AES-256-GCM algorithm is used for decryption, and the decryption key is managed by the hardware security module (HSM) to ensure that the key does not leave the library.

[0035] In an embodiment of the present application, configuring the mapping relationship database specifically includes: receiving a device identifier entry operation on the visual configuration interface to generate a device registration record; associating at least one IoT platform type and the corresponding account permission group with the device registration record; encrypting and storing the account authentication credential through the key management service, and establishing an index relationship between the device identifier and the encrypted credential.

[0036] Exemplarily, when the device identifier is "HW-THERM-001", the queried mapping relationship may be: { "platformType": "HW_IOT", "apiEndpoint": "https: / / iot.huaweicloud.com:443 / v5 / iotda / region", "encryptedCredential": "U2FsdGVkX1+3C7Zq...", "accountGroup": "PROD_GROUP_02" } The actual certificate obtained after decryption is the access key pair of the Huawei Cloud IoT platform (AccessKey ID: AKID, AccessKey Secret: AKS).

[0037] It can be understood that if the device is found to be unregistered or configured abnormally (such as the apiEndpoint field is empty), the system will interrupt the process and return an error code. For example, the following response is generated: { "code": 404, "message": "Device mapping not found" } At the same time, the alarm service is triggered, and the abnormal device identifier is written into the audit log for subsequent troubleshooting of configuration missing problems by the operation and maintenance personnel.

[0038] It should be noted that the dynamic acquisition mechanism of the account authentication certificate provides a data basis for the dynamic injection of subsequent protocol adapters. For example, when the target platform type is "HW_IOT", the system will use the decrypted Huawei Cloud AccessKey Secret to generate a request signature, while the Alibaba Cloud platform needs to use the temporary token of the RAM role.

[0039] Step 103: Based on the target Internet of Things platform type, call the corresponding protocol adapter from the dynamic adapter registry, and through the credential processing module of the protocol adapter, dynamically write the account authentication credential into the request header or message body of the request to be sent in the protocol format supported by the target Internet of Things platform.

[0040] In this embodiment, the dynamic adapter registry realizes the dynamic loading and instantiation management of the protocol adapter through the factory mode. Exemplarily, the system scans the classes with the @PlatformAdapter annotation in the class path through the Java reflection mechanism during the startup phase, for example: @PlatformAdapter(platformType = "HW_IOT") public class HuaweiIoTAdapter implements ProtocolAdapter { / / Implement Huawei Cloud protocol conversion logic } It can be understood that the platformType attribute value of the annotation strictly matches the platform type code queried in step 102 to ensure the accuracy of adapter calls. After the scanning is completed, the system registers the fully qualified name of the adapter class and the instantiated object into the ConcurrentHashMap to form a memory mapping table of "platform type code → adapter instance".

[0041] In an embodiment of the present application, a dynamic adapter registration table is constructed, which specifically includes: scanning the annotation identifiers of predefined adapter implementation classes during the system initialization phase; instantiating the scanned adapter classes and registering them into a memory hash table; where the key of the hash table is the platform type code and the value is the reference pointer of the adapter instance.

[0042] In an embodiment of the present application, through the credential processing module of the protocol adapter, the account authentication credential is dynamically written into the request header or message body of the request to be sent in the protocol format supported by the target Internet of Things platform, which specifically includes: when the protocol corresponding to the protocol adapter is the HTTP protocol, writing the account authentication credential into the Authorization field of the request header to be sent; when the protocol corresponding to the protocol adapter is the MQTT protocol, writing the account authentication credential into the auth field of the request message body to be sent; for platforms that require dynamic signature, calling the signature algorithm of the adapter to generate a time-limited credential and writing it.

[0043] Exemplarily, when the target platform type is "HW_IOT", the protocol adapter performs the following operations: 1. Extract the Huawei Cloud AccessKey ID (AK) and Secret Key (SK) from the decryption result of step 102.

[0044] 2. Generate the current request timestamp (such as 2023-09-01T12:00:00Z) and splice the signature string according to the Huawei Cloud specification: StringToSign = AK + "\n" + timestamp + "\n" + MD5(requestBody) 3. Encrypt StringToSign with HmacSHA256 using SK to generate the signature value signature.

[0045] 4. Set the Authorization header to Bearer {AK}:{signature} and write the timestamp into the X-Sdk-Date header.

[0046] It is understandable that this dynamic injection mechanism (the core innovation point of claim 4) enables the same set of account credentials to be automatically adapted according to the authentication rules of different platforms without the need for manual format conversion at the front end or business layer. For example, when the same device migrates from Huawei Cloud to Alibaba Cloud, only the platform type code needs to be updated in the mapping relationship database, and the protocol adapter can automatically switch the signature algorithm and injection location to achieve a smooth migration with zero code modification.

[0047] It should be noted that the protocol conversion capabilities of the adapters are uniformly managed through predefined interface specifications. All adapters must implement the following methods of the ProtocolAdapter interface: public interface ProtocolAdapter { void injectCredentials(Request request, String credentials); / / Credential injection byte[] convertProtocol(Map<String, Object>params); / / Protocol conversion void handleResponse(byte[] rawData); / / Response handling } This design ensures the behavioral consistency of different platform adapters and provides a standardized input-output interface for the protocol conversion in step 104.

[0048] Step 104: According to the platform API interface address, convert the data query parameters in the device operation request into the protocol format supported by the target Internet of Things platform, and merge the converted data query parameters with the request header or message body of the request to be sent to generate the request to be sent.

[0049] In this embodiment, the core of the protocol format conversion lies in dynamically adapting to the API specifications of the target platform, and achieving dual adaptation of the data structure and transmission protocol through parameter mapping templates. Exemplarily, the system pre-sets YAML format template files bound to the platform type. For example, the template definition for Huawei Cloud IoT is as follows: parameters: temperature: targetKey: tempValue type: float unitConversion: "℃→℉" operation: targetKey: cmd type: enum mapping: "readTemperature": 0x201 It can be understood that the template is automatically generated by parsing the target platform API documentation or manually maintained by developers to ensure that the parameter names, data types, and unit conversion rules strictly match the platform requirements.

[0050] In an embodiment of the present application, according to the platform API interface address, the data query parameters in the device operation request are converted into a protocol format supported by the target Internet of Things platform, specifically including: parsing the required parameter list defined in the target Internet of Things platform API documentation to generate a parameter mapping template; performing key name replacement and type coercion on the original parameters in the device operation request according to the mapping template; and encapsulating the converted parameters into HTTP REST, MQTT, or CoAP message packets according to the transmission protocol type supported by the target Internet of Things platform.

[0051] It should be noted that for the HTTP REST protocol: the converted parameters are encapsulated into an application / json request body, and the authentication header injected in step 103 is added. For example, a complete HTTP request is generated: POST / v5 / iotda / region / devices / commands HTTP / 1.1 Authorization: Bearer AKID:signature Content-Type: application / json {"tempValue":77, "cmd":0x201} For the MQTT protocol: a PUBLISH message is constructed, the parameters are written into the message body, and the QoS level is set. For example, the Alibaba Cloud IoT platform requires the message body to be: { "id": "123", "version": "1.0", "params": {"tempValue":77} } At the same time, the device identifier is embedded in the message topic: / sys / ${productKey} / ${deviceId} / thing / event / property / post.

[0052] CoAP protocol: Convert parameters into CBOR binary format, and add Message ID and Token header fields to meet the transmission requirements of low-power devices.

[0053] Exemplarily, when the device operation request is to query temperature data, the original front-end parameters are {"operation":"readTemperature"}, and after protocol conversion: for the Huawei Cloud IoT platform, a JSON request body containing cmd:0x201 is generated; for Modbus devices that support binary protocols, it is converted into an RTU frame in the format of 01 03 00 01 00 01 D5 CA.

[0054] It can be understood that the converted data query parameters need to be merged with the request structure that has been injected with authentication information in step 103. For example, in the HTTP protocol, the authentication header (Authorization) is combined with the JSON request body to form a complete request message; in the MQTT protocol, the authentication fields (clientId / password) are merged with the message body parameters and then published to the specified topic.

[0055] It should be noted that the merging operation is automatically completed by the protocol encapsulation module of the adapter to ensure that the request message contains both the authentication identifier and the service parameters. For example, after the MQTT protocol adapter writes the authentication information in the CONNECT message, it carries the converted parameters in the PUBLISH message to form an end-to-end compliant communication message.

[0056] The technical value of this step is that through the templated conversion mechanism, the differences in API specifications of different platforms are shielded. For example, when a certain platform upgrades the API version and causes the parameter name to change, only the definition of targetKey in the template file needs to be updated, and the code logic does not need to be modified to achieve smooth migration, significantly improving the maintainability of the system.

[0057] Step 105: Send the request to be sent to the target IoT platform through the asynchronous message queue, and listen for the response data returned by the platform.

[0058] In this embodiment, the asynchronous message queue adopts a hierarchical architecture design, and realizes highly reliable communication through platform type isolation and differential policy configuration (corresponding to the message channel and retry policy of claim 6). Exemplarily, the system creates the huawei_iot_command topic for the Huawei Cloud IoT platform and the aliyun_link_command topic for the Alibaba Cloud Link Platform, and each topic is associated with an independent consumer group and partition policy. It can be understood that this design can avoid mutual interference between requests from different platforms. For example, different processing strategies are required for the QoS 1 level requirement of Alibaba Cloud MQTT messages and the short timeout feature of Huawei Cloud HTTP requests.

[0059] In an embodiment of the present application, before sending a request to be sent to a target Internet of Things platform through an asynchronous message queue, the method further includes: creating an independent message channel for each target Internet of Things platform type, and configuring differential retry policies and timeout thresholds; configuring a sending logic to record the request sending timestamp and the platform response status code in the message persistent storage; configuring a sending exception handling logic to trigger an adaptive retransmission mechanism according to the retry policy when detecting that the platform response times out.

[0060] Specifically, the request sending and listening process includes the following steps: 1. Message event encapsulation: Wrap the request to be sent generated in step 104 into a message event, and the event structure includes a device identifier, a platform type code, a request message binary stream, the current timestamp, and a retry counter (initial value is 0). Exemplarily, event serialization adopts the Protocol Buffers format to improve transmission efficiency: message CommandEvent { string device_id = 1; string platform_type = 2; bytes payload = 3; int64 timestamp = 4; int32 retry_count = 5; } 2. Message Delivery: Deliver events to the corresponding message channels according to the platform type code. For example, Huawei Cloud events are published to the hw_iot Exchange of RabbitMQ, and Alibaba Cloud events are published to the aliyun.link.commandTopic of Kafka. During the delivery process, the differential retry policy configured in Right 6 takes effect: For platforms using the HTTP protocol: Set the maximum number of retries to 3 times, the timeout threshold to 5 seconds, and adopt the exponential backoff strategy (wait 1 second after the first failure, 2 seconds for the second time, and 4 seconds for the third time). For platforms using the MQTT protocol: Set the maximum number of retries to 5 times, the timeout threshold to 10 seconds, and adopt the fixed interval retry (with an interval of 2 seconds each time).

[0061] 3. Response Monitoring: The consumer thread monitors the response Topic of the message queue, such as hw_iot_response for Huawei Cloud and aliyun_link_response for Alibaba Cloud. After the response data is deserialized, update the request status and write it to the persistent storage (associated with the persistent record of Right 6). Exemplarily, the command_log collection in MongoDB records the following fields: { "deviceId": "HW-THERM-001", "platform": "HW_IOT", "status": "SUCCESS", "responseCode": 200, "timestamp": ISODate("2023-09-01T12:00:00Z"), "retryCount": 0 } It can be understood that the introduction of the asynchronous message queue effectively solves the system throughput bottleneck caused by synchronous blocking. For example, in a high-concurrency scenario, even if the response latency of a certain platform interface soars, the system can achieve traffic shaping through message accumulation and consumption rate control, avoiding an overall service avalanche. At the same time, the request logs in the persistent storage provide the ability for complete link tracing for fault backtracking, such as quickly locating the context information of abnormal requests through the deviceId and timestamp fields.

[0062] It should be noted that the response monitoring module needs to be compatible with the differences in return formats of different platforms. For example, the Huawei Cloud HTTP response is in JSON format, while the Modbus TCP device returns a binary data stream. The listener temporarily stores the original response data in a cache middleware (such as Redis Stream) for the subsequent step 106 to perform standardized cleaning. This design ensures the decoupling of the response processing stage from the protocol details and improves the scalability of the system.

[0063] Step 106, after the response data is monitored, return the response data to the front-end application.

[0064] In an embodiment of the present application, to implement returning the standardized response data to the front-end application, before returning the response data to the front-end application, the method further includes: performing standardized cleaning on the response data, specifically including: extracting the business valid fields in the platform response data, filtering the platform internal status codes and debugging information; uniformly converting the heterogeneous data units into the International System of Units; performing cross-platform semantic mapping on the enumerated fields to generate a standardized device status description.

[0065] In this embodiment, the standardized cleaning process is implemented through a three-level processing pipeline, aiming to eliminate the heterogeneity of the data returned by different IoT platforms. Exemplarily, the original response returned by a certain temperature sensor through the Huawei Cloud IoT platform is: { "code": 20000, "data": { "tempValue": 77.5, "hw_extension": "0xFA01", "unit": "F" }, "requestId": "hw123" } It should be noted that the cleaning rules are dynamically loaded through a pluggable rule engine (technical extension of claim 7). For example, when adding a new LoRaWAN platform, the operation and maintenance personnel only need to configure the following rules in the management interface: Field extraction rule: JSONPath = $.result.measurement; Unit conversion rule: Original unit = dBm → Standard unit = dBm (no conversion required); Status mapping rule: "success" → 1, "fail" → 0; The system automatically generates the corresponding cleaning logic, and the new platform can be supported without modifying the code.

[0066] It is understandable that the standardized data is returned to the front-end application through a unified interface format. Regardless of the underlying IoT platform being connected, the responses received by the front-end contain fixed fields: status: the operation status (1 for success / 0 for failure); value: the data value (numeric or string type); unit: the identifier of the International System of Units; timestamp: the data collection time (in ISO8601 format).

[0067] It should be noted that the cleaned data will be synchronously updated to the device status cache. The latest status of the device stored in Redis adopts a Sorted Set structure, with the device identifier as the Member and the timestamp as the Score, supporting fast retrieval of historical status by time range. Meanwhile, the standardized data is written into the Elasticsearch log cluster, and the index fields include deviceId, valueType, and timestamp, facilitating subsequent big data analysis or generating device health reports.

[0068] In an embodiment of the present application, the method further includes: regularly scanning the last usage timestamp of each account in the mapping relationship database; generating an alarm event for accounts that exceed the preset idle period, and pushing the alarm information to the management terminal; receiving an account freezing instruction from the management terminal, updating the status flag of the corresponding account in the mapping relationship database to disabled, and terminating subsequent device operation requests initiated through this account.

[0069] The above is the method embodiment proposed in the present application. Based on the same inventive concept, the embodiments of the present application also provide a unified access management device for multi-platform IoT devices, and its structure is as Figure 2 shown.

[0070] Figure 2 This is a schematic diagram of the internal structure of a unified access management device for multi-platform IoT devices provided by the embodiment of the present application. As Figure 2 shown, the device includes: at least one processor 201; and, a memory 202 communicatively connected to the at least one processor; wherein, the memory 202 stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor 201, so that the at least one processor 201 can: Receive a device operation request from a front-end application and extract the device unique identifier carried in the device operation request; according to the device unique identifier, obtain the corresponding mapping relationship information from a pre-configured mapping relationship database; wherein, the mapping relationship information includes: the target Internet of Things platform type, the platform API interface address, and the account authentication credential; based on the target Internet of Things platform type, call the corresponding protocol adapter from a dynamic adapter registry to dynamically write the account authentication credential into the request header or message body of the request to be sent in a protocol format supported by the target Internet of Things platform through the credential processing module of the protocol adapter; according to the platform API interface address, convert the data query parameters in the device operation request into a protocol format supported by the target Internet of Things platform, and merge the converted data query parameters with the request header or message body of the request to be sent to generate a request to be sent; send the request to be sent to the target Internet of Things platform through an asynchronous message queue and listen for the response data returned by the platform; after the response data is listened, return the response data to the front-end application.

[0071] Some embodiments of the present application provide a non-volatile computer storage medium for unified access management of multi-platform Internet of Things devices corresponding to Figure 1 , storing computer-executable instructions, and the computer-executable instructions are set to: Receive a device operation request from a front-end application and extract the device unique identifier carried in the device operation request; according to the device unique identifier, obtain the corresponding mapping relationship information from a pre-configured mapping relationship database; wherein, the mapping relationship information includes: the target Internet of Things platform type, the platform API interface address, and the account authentication credential; based on the target Internet of Things platform type, call the corresponding protocol adapter from a dynamic adapter registry to dynamically write the account authentication credential into the request header or message body of the request to be sent in a protocol format supported by the target Internet of Things platform through the credential processing module of the protocol adapter; according to the platform API interface address, convert the data query parameters in the device operation request into a protocol format supported by the target Internet of Things platform, and merge the converted data query parameters with the request header or message body of the request to be sent to generate a request to be sent; send the request to be sent to the target Internet of Things platform through an asynchronous message queue and listen for the response data returned by the platform; after the response data is listened, return the response data to the front-end application.

[0072] Each embodiment in the present application is described in a progressive manner. The same or similar parts among the embodiments can be referred to each other, and the differences between each embodiment and other embodiments are emphasized. In particular, for the Internet of Things device and medium embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the description of the method embodiments.

[0073] The system, medium, and method provided by the embodiments of the present application correspond one by one. Therefore, the system and the medium also have beneficial technical effects similar to those of their corresponding methods. Since the beneficial technical effects of the method have been described in detail above, the beneficial technical effects of the system and the medium will not be elaborated here.

[0074] Those skilled in the art should understand that the embodiments of the present application can be provided as a method, a system, or a computer program product. Therefore, the present application can take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present application can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0075] The present application is described with reference to the flowcharts and / or block diagrams of methods, apparatuses (systems), and computer program products according to the embodiments of the present application. It should be understood that each flow and / or block in the flowchart and / or block diagram can be implemented by computer program instructions, and the combination of flows and / or blocks in the flowchart and / or block diagram can also be implemented. These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing devices to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing devices generate a device for implementing the functions specified in Figure 1 one flow or multiple flows and / or blocks Figure 1 one block or multiple blocks.

[0076] These computer program instructions can also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer-readable memory generate a manufactured article including an instruction device, and the instruction device implements the functions specified in Figure 1 one flow or multiple flows and / or blocks Figure 1 one block or multiple blocks.

[0077] These computer program instructions can also be loaded onto a computer or other programmable data processing device, so that a series of operation steps are executed on the computer or other programmable device to generate a computer-implemented process. Thus, the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in Figure 1 one flow or multiple flows and / or blocks Figure 1 one block or multiple blocks.

[0078] In a typical configuration, a computing device includes one or more processors (CPUs), an input / output interface, a network interface, and a memory.

[0079] The memory may include non-permanent memory in the form of computer-readable media, random access memory (RAM) and / or non-volatile memory such as read-only memory (ROM) or flash RAM. The memory is an example of computer-readable media.

[0080] Computer-readable media includes permanent and non-permanent, removable and non-removable media that can store information by any method or technology. The information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory media such as modulated data signals and carrier waves.

[0081] It should also be noted that the term "comprising", "including" or any other variant thereof is intended to cover non-exclusive inclusion, such that a process, method, article or apparatus comprising a series of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article or apparatus. Without further limitation, an element defined by the statement "comprising an..." does not exclude the presence of additional identical elements in the process, method, article or apparatus comprising the element.

[0082] The above description is only for the embodiments of the present application and is not intended to limit the present application. For those skilled in the art, various changes and modifications can be made to the present application. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principle of the present application shall be included within the scope of the claims of the present application.

Claims

1. A method for unified access management of multi-platform IoT devices, characterized in that: The method comprises: Receive a device operation request from a front-end application, and extract a device unique identifier carried in the device operation request; According to the device unique identifier, corresponding mapping relationship information is obtained from a preconfigured mapping relationship database; wherein the mapping relationship information includes: target IoT platform type, platform API interface address and account authentication credentials; Based on the target IoT platform type, calling a corresponding protocol adapter from a dynamic adapter registry, so as to dynamically write the account authentication credential into a request header or a message body of a request to be sent in a protocol format supported by the target IoT platform through a credential processing module of the protocol adapter; According to the platform API interface address, convert the data query parameters in the device operation request into a protocol format supported by the target IoT platform, and merge the converted data query parameters with the request header or message body of the request to be sent to generate a request to be sent; Send the request to be sent to the target IoT platform through an asynchronous message queue, and monitor the response data returned by the platform; After the response data is monitored, the response data is returned to the front-end application.

2. A method for unified access management of multi-platform IoT devices according to claim 1, characterized in that: The method further comprises: Configure the mapping relationship database, including: Receive device identifier input operation in the visual configuration interface and generate device registration record; Associating at least one IoT platform type and a corresponding account permission group for the device registration record; The account authentication credentials are encrypted and stored through a key management service, and an index relationship between the device identifier and the encrypted credentials is established.

3. A method for unified access management of multi-platform IoT devices according to claim 1, characterized in that: The method further comprises: Build a dynamic adapter registry, including: Scan the annotation identifier of the predefined adapter implementation class during the system initialization phase; The scanned adapter class is instantiated and registered in a memory hash table; wherein the key of the hash table is the platform type code, and the value is a reference pointer to the adapter instance.

4. A method for unified access management of multi-platform IoT devices according to claim 1, characterized in that: The account authentication credential is dynamically written into the request header or message body of the request to be sent in the protocol format supported by the target IoT platform through the credential processing module of the protocol adapter, specifically including: When the protocol corresponding to the protocol adapter is the HTTP protocol, writing the account authentication credential into the Authorization field of the request header to be sent; When the protocol corresponding to the protocol adapter is the MQTT protocol, writing the account authentication credential into the auth field of the request message body to be sent; For platforms that require dynamic signatures, call the adapter's signature algorithm to generate a time validity certificate and write it.

5. A method for unified access management of multi-platform IoT devices according to claim 1, characterized in that: According to the platform API interface address, the data query parameters in the device operation request are converted into a protocol format supported by the target IoT platform, specifically including: Parse the required parameter list defined in the target IoT platform API document and generate a parameter mapping template; Replace the key names and force type conversion of the original parameters in the device operation request according to the mapping template; According to the transmission protocol type supported by the target IoT platform, the converted parameters are encapsulated as HTTP REST, MQTT or CoAP message packets.

6. A method for unified access management of multi-platform IoT devices according to claim 1, characterized in that: Before sending the request to be sent to the target Internet of Things platform through the asynchronous message queue, the method further includes: Create independent message channels for each target IoT platform type and configure differentiated retry strategies and timeout thresholds; Configure the sending logic to record the request sending timestamp and platform response status code in the message persistent storage; The sending exception handling logic is configured to trigger the adaptive resending mechanism according to the retry strategy when a platform response timeout is detected.

7. A method for unified access management of multi-platform IoT devices according to claim 1, characterized in that: Before returning the response data to the front-end application, the method further includes: Extract business valid fields from platform response data and filter platform internal status codes and debugging information; Convert heterogeneous data units into the international standard system of units; Perform cross-platform semantic mapping on enumeration fields to generate standardized device status descriptions.

8. A method for unified access management of multi-platform IoT devices according to claim 1, characterized in that: The method further comprises: Periodically scan the last usage timestamp of each account in the mapping relationship database; Generate alarm events for accounts that exceed the preset idle period and push the alarm information to the management terminal; An account freezing instruction is received from the management terminal, a status mark of the corresponding account in the mapping database is updated to be disabled, and subsequent device operation requests initiated through the account are terminated.

9. A unified access management device for multi-platform IoT devices, characterized in that: The device comprises: at least one processor; and, a memory communicatively coupled to the at least one processor; In which, the memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute a unified access management method for multi-platform Internet of Things devices as described in any one of claims 1-8.

10. A non-volatile computer storage medium for unified access management of multi-platform IoT devices, storing computer executable instructions, characterized in that: When the computer executable instructions are executed, a multi-platform IoT device unified access management method as described in any one of claims 1-8 is implemented.

Images