A device unified management method, device and medium under multiple internet of things platforms

Abstract

The specification discloses a device unified management method under multiple Internet of Things platforms, a device and a medium. In the scheme, an access request for a device group to be managed is received from an upstream business system, then a target platform for managing the device group is determined according to a platform type contained in the access request, a platform connector of the target platform is called to allocate a target platform instance for managing the device group in the target platform, and a native group identifier of the device group under the target platform instance is determined, a global device group identifier for the device group is generated, and a first mapping relationship between the global device group identifier and the native device group identifier is established, so that the upstream business system can perform Internet of Things control on Internet of Things devices belonging to the device group through the target platform instance based on the first mapping relationship.

Description

Technical Field

[0001] This specification relates to the field of Internet of Things (IoT) technology, and more particularly to a method, device, and medium for unified management of devices across multiple IoT platforms. Background Technology

[0002] With the popularization of IoT technology, enterprises often need to connect to multiple IoT cloud platforms to meet business continuity or compliance requirements. However, different IoT cloud platforms have significant differences in device access protocols, identity authentication mechanisms (such as key authentication and certificate authentication), object model definitions, and API interface specifications.

[0003] In existing technologies, if upstream business systems need to interface with multiple IoT cloud platforms, they typically need to develop independent adaptation modules for each IoT cloud platform to handle the unique parameter formats and authentication credentials of each platform. This decentralized development leads to high coupling of business code and huge maintenance costs. Once the IoT cloud platform's strategy is adjusted or migrated, the upstream business system needs to undergo extensive reconstruction.

[0004] Furthermore, due to the lack of a unified middleware layer to shield semantic and structural differences, cross-platform data aggregation and control are often difficult, making it hard to achieve dynamic expansion of IoT management.

[0005] Therefore, how to achieve unified access, unified modeling, and unified control of multiple different IoT platforms without modifying upstream business code is a technical problem that urgently needs to be solved. Summary of the Invention

[0006] In view of the above, one or more embodiments of this specification provide the following technical solutions: According to a first aspect of one or more embodiments of this specification, a method for unified management of devices across multiple IoT platforms is proposed, the method being applied in a management system, the method comprising: Receive an access request from an upstream business system for a group of devices to be managed. The access request includes: the platform type of the IoT platform that manages the group of devices, and the group of devices contains at least one IoT device. Based on the platform type, determine the target platform for managing the device group; Invoke the platform connector of the target platform to allocate a target platform instance for managing the device group in the target platform, and determine the native device group identifier of the device group under the target platform instance; A global device group identifier is generated for the device group, and a first mapping relationship is established between the global device group identifier and the native device group identifier, so that the upstream business system can perform IoT control on the IoT devices belonging to the device group through the target platform instance based on the first mapping relationship.

[0007] According to a second aspect of one or more embodiments of this specification, an electronic device is provided for storing a memory of processor-executable instructions; wherein the processor implements the steps of the method described above by executing the executable instructions.

[0008] According to a third aspect of one or more embodiments of this specification, a computer-readable storage medium is provided that stores computer instructions thereon, which, when executed by a processor, implement the steps of the method described above.

[0009] According to a fourth aspect of one or more embodiments of this specification, a computer program product is provided, comprising a computer program / instructions that, when executed by a processor, implement the steps of the method described above.

[0010] As can be seen from the method for unified management of devices under multiple IoT platforms provided in this specification, the system receives an access request from an upstream business system for a group of devices to be managed. Then, based on the platform type contained in the access request, it determines the target platform for managing the device group, calls the platform connector of the target platform to allocate a target platform instance for managing the device group in the target platform, determines the native group identifier of the device group under the target platform instance, generates a global device group identifier for the device group, and establishes a first mapping relationship between the global device group identifier and the native device group identifier. This allows the upstream business system to perform IoT control on the IoT devices belonging to the device group through the target platform instance based on the first mapping relationship.

[0011] As can be seen from the above method, by introducing a platform connector and global identifier mapping mechanism, decoupling between the upstream business system and the IoT platform is achieved. By receiving access requests containing the platform type, the management system can dynamically select the corresponding target platform and its connector, thereby allocating the appropriate platform instance at the underlying level. Crucially, the system generates a global device group identifier independent of the IoT platform and establishes a mapping relationship between it and the underlying native device group identifier. This means that the upstream business system only needs to hold the global device group identifier to indirectly control devices managed under any type of IoT platform through a unified management system, without needing to concern itself with the specific type of IoT platform or adapt to the unique API interfaces of each IoT platform. This eliminates the need for code refactoring when the upstream business system faces IoT platform switching or expansion, significantly reducing system coupling and maintenance costs, and achieving unified device management in a multi-IoT platform environment. Attached Figure Description

[0012] Figure 1 This specification provides a flowchart illustrating a unified device management method across multiple IoT platforms. Figure 2 A flowchart for the device group creation and heterogeneous adaptation method provided in this specification; Figure 3 A flowchart of the parameter name alignment and downlink control method provided in this specification; Figure 4 A flowchart of the device registration and global identifier mapping method provided in this specification; Figure 5 This is a schematic diagram illustrating the process of converting a standard object model into an object model supported by the underlying IoT platform, as provided in this specification. Figure 6 A flowchart of the uplink data processing and status synchronization method provided in this specification; Figure 7 This is a schematic structural diagram of a device provided in this specification; Figure 8 This specification provides a schematic diagram of a device for unified management of devices across multiple IoT platforms. Detailed Implementation

[0013] The user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this manual are all information and data authorized by the user or fully authorized by all parties. The collection, use and processing of related data shall comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation portals shall be provided for users to choose to authorize or refuse.

[0014] With the rapid development of IoT technology, more and more enterprises are deploying large-scale IoT devices to achieve intelligent operations. In practical applications, to meet the needs of business continuity, data compliance, or cost optimization, enterprises often need to connect to multiple different underlying IoT cloud platforms simultaneously. These IoT platforms differ significantly in device access protocols, authentication mechanisms, object model definitions, and API interface specifications.

[0015] In existing technical solutions, if an upstream business system needs to connect to multiple underlying IoT platforms, it is usually necessary to develop independent adaptation modules for each platform.

[0016] For example, on Alibaba Cloud's key-based authentication platform, business systems need to maintain Product Keys and Device Secrets; while on AWS's certificate-based authentication platform, business systems need to handle complex certificate chains and pre-built templates. This decentralized development model results in high code coupling in business systems and huge maintenance costs. When the underlying IoT platform's strategy is adjusted (such as instance shutdown or API changes), the upstream business systems must undergo extensive code refactoring and regression testing. Furthermore, the object model definition formats differ across platforms. The same physical attribute (such as "temperature") may correspond to different field names, data types, or hierarchical structures on different platforms.

[0017] Therefore, the lack of a unified middleware layer in existing technologies to shield these semantic and structural differences forces upstream business systems to use hard-coding to handle platform-specific formats when receiving data reported by devices or issuing control commands. This not only increases development complexity but also makes cross-platform data aggregation and analysis more difficult.

[0018] Although there are some open-source IoT platforms or specific vendor migration tools on the market, they either lack native cross-platform unified object model capabilities, requiring developers to implement complex mapping logic themselves; or they only support one-way migration between specific platforms, and cannot achieve true hot-swapping and horizontal scaling across multiple IoT platforms.

[0019] Therefore, how to achieve unified access, unified modeling, and unified control of heterogeneous IoT platforms without modifying upstream business code is a technical problem that urgently needs to be solved.

[0020] To facilitate understanding of the unified device management method for multiple IoT platforms provided in this manual, the following explanations will cover some of the concepts involved: Application Programming Interface (API): refers to the set of standard interfaces for interaction between upstream business systems and the unified management system.

[0021] The Internet of Things (IoT) refers to the use of various information sensors, radio frequency identification (RFID) technology, global positioning systems, and other devices and technologies to collect real-time information on any object or process that needs to be monitored, connected, or interacted with. This information includes sound, light, heat, electricity, mechanics, chemistry, biology, location, and other necessary data. Through various possible network access methods, it enables ubiquitous connectivity between things and between things and people, achieving intelligent perception, identification, and management of objects and processes.

[0022] Message Queuing Telemetry Transport (MQTT): A lightweight communication protocol based on the publish / subscribe model, widely used for communication of Internet of Things (IoT) devices.

[0023] Transport Layer Security (TLS): A security protocol used to provide confidentiality and data integrity between two communicating applications.

[0024] Global device group identifier: A unique string generated by the unified management system to identify a specific device group in the upstream business system, and is unrelated to the native identifier of the underlying physical network platform.

[0025] Native Device Group Identifier: A unique identifier used within the underlying IoT platform to identify device groups, such as Alibaba Cloud's Product Key or AWS Provisioning Template ARN.

[0026] Virtual group key: A unified credential generated by a unified management system for certificate-based authentication platforms, used to simulate the key authentication experience.

[0027] Global Device Identifier: A unique string generated by the unified management system to identify a single device in the upstream business system.

[0028] Native Device Identifier: A unique identifier used within the underlying IoT platform to identify a single device, such as Alibaba Cloud's Device Name or AWS's Thing Name.

[0029] The technical solution to be protected in this specification will now be described in detail with reference to the accompanying drawings.

[0030] Figure 1This document provides a flowchart illustrating a unified device management method across multiple IoT platforms. Figure 1 As shown, the method includes the following steps: This specification provides a unified management method for devices across multiple IoT platforms. This method aims to address the problems of high coupling and maintenance difficulties in existing technologies when dealing with heterogeneous IoT cloud platforms, caused by differences in access protocols, authentication mechanisms, and data formats. By constructing a unified IoT foundation, it provides standardized API interfaces to upstream business systems while shielding the implementation details of the underlying platforms, achieving unified device access, unified modeling, and unified control.

[0031] Figure 1 This specification illustrates an architecture diagram of a unified device management system for multiple IoT platforms. Figure 1 As shown.

[0032] The system mainly includes an upstream business system 101, a unified management system 102, and multiple underlying IoT platforms 103. The upstream business system 101 can be a smart home management platform, an industrial internet monitoring system, etc., running on a server cluster, and interacts with the unified management system 102 through standard APIs. The unified management system 102 is deployed in the cloud or a local data center and includes a platform connector module 1021, a mapping engine module 1022, a device model engine module 1023, and a storage module 1024.

[0033] Platform connector module 1021 is responsible for establishing connections with different underlying IoT platforms 103, and may include, for example... Figure 1 The diagram shows connectors such as Alibaba Cloud 1021a, AWS 1021b, and Tuya connector 1021c. The mapping engine module 1022 maintains the mapping relationship between global identifiers and native identifiers. The object model engine module 1023 handles the conversion between standard object models and native parameter names. The storage module 1024 persists storage instance configurations, mapping relationships, object model definitions, and device status data.

[0034] The underlying IoT platform includes, but is not limited to, conventional IoT platforms such as Alibaba Cloud IoT Platform 103a, AWS IoT Core Platform 103b, and Tuya Smart Platform 103c. The components communicate with each other via wired or wireless networks.

[0035] The following combination Figures 2 to 6 This section describes in detail the specific implementation process of the unified device management method based on the above system architecture. This method can be implemented by... Figure 1 This is achieved through a unified management system.

[0036] Figure 2A flowchart illustrating the method for creating and heterogeneously adapting to device groups provided in this specification. This method includes the following steps: S200: Receive an access request from an upstream business system for a group of devices to be managed. The access request includes: the platform type of the IoT platform that manages the group of devices, and the group of devices contains at least one IoT device.

[0037] In this step, the upstream business system initiates a request to create a device group. This request requires specifying the type of underlying physical network platform selected. Therefore, the platform type reflects which physical network platform the upstream business system specifically chooses to manage the device group. For example, by specifying the platform type, it can be determined which physical network platform the upstream business system needs to select. Figure 1 Which IoT platform among "Alibaba Cloud", "AWS" or "Tuya"?

[0038] Correspondingly, the platform type determines which IoT platform connector the upstream business system will choose for operation. In addition, the request can also include basic information such as the name of the device group and its network connection method (e.g., Wi-Fi, cellular network). After receiving the access request, the unified management system can parse the platform type parameter from it, which will serve as the basis for subsequent routing selection.

[0039] S202: Determine the target platform for managing the device group based on the platform type.

[0040] Based on the platform type parsed in step S200, the unified management system searches for a matching target platform from the pre-configured platform list. Once the target platform is determined, the unified management system loads the platform connector corresponding to that target platform. For example, if the platform type points to an upstream business system that needs to use AWS, then AWS connector 1021b is loaded; if it's Alibaba Cloud, then Alibaba Cloud connector 1021a is loaded. This approach allows the unified management system to dynamically adapt to newly added platform types; only new connector plugins need to be developed, without modifying the core logic.

[0041] S204: Invoke the platform connector of the target platform to allocate a target platform instance for managing the device group in the target platform, and determine the native device group identifier of the device group under the target platform instance.

[0042] In practical applications, an IoT platform can support multiple similar platform instances (such as multiple Alibaba Cloud instances to support horizontal scaling). In this case, a specific target platform instance can be selected based on the load balancing strategy or the principle of proximity to the region.

[0043] In this step, the platform connector establishes a session with the underlying IoT platform using pre-stored configuration information (such as Access Key, Secret Key, Endpoint, etc.) and initiates an API call to create a device group. Because the authentication mechanisms and returned data structures of different IoT platforms vary significantly, this step employs different processing strategies for different platform types, specifically including the following two main implementation methods: As a common implementation method, when the target platform is a key-based authentication IoT platform, the unified management system can first obtain the configuration information of the target platform instance. This configuration information may include the access credentials and access address corresponding to the target platform instance. Then, through the platform connector, a creation request can be initiated using the configuration information to create a device group identifier for the target platform instance targeting a device group. Finally, the unified management system can receive the device group identifier returned by the target platform (or the target platform instance) and use this device group identifier as the native device group identifier.

[0044] For example, in the Alibaba Cloud IoT platform, the connector calls the Create Product interface, passing in configuration parameters including the device group name. The Alibaba Cloud IoT platform returns a Product Key and a Product Secret. The unified management system can then directly use the Product Key as the native device group identifier. This approach directly utilizes the underlying IoT platform's existing key system.

[0045] However, for certificate-based IoT platforms, the authentication mechanism is more complex and cannot directly return a simple key identifier. Therefore, this embodiment adopts the following approach: Specifically, if the target platform is a certificate-based IoT platform, the configuration information obtained by the unified management system may include: the access address corresponding to the target platform instance and the authentication parameters corresponding to the target platform instance. Then, through the platform connector corresponding to the target platform, a creation request is sent using this configuration information to create a pre-configured certificate template identifier for the target platform instance targeting the device group. Finally, the unified management system receives the pre-configured certificate template identifier returned by the target platform (or the target platform instance) and generates a native device group identifier based on the pre-configured certificate template identifier.

[0046] Taking AWS IoT Core as an example, the connector first calls the Create Provisioning Template interface to create a provisioning template. This template defines the role permissions and pre-provisioning hooks for device registration. AWS returns the template's ARN (Amazon Resource Name) as the provisioning certificate template identifier. Because the ARN format is complex and not suitable for direct exposure to upstream business systems as a unified credential, the unified management system needs to further process it to generate a unified native device group identifier.

[0047] To further shield the complexity of the underlying certificate template identifier and achieve a unified credential experience similar to the key platform, the unified management system can generate a virtual group key bound to a pre-set certificate template identifier and use this virtual group key as the native device group identifier.

[0048] Specifically, taking AWS as an example, the unified management system generates a virtual group key that conforms to a preset format specification (such as a UUID or a string with a specific prefix). Subsequently, the unified management system establishes a binding relationship between this virtual group key and the pre-built certificate template (ARN) returned by AWS in its internal database. Afterward, within the unified management system, this virtual group key is regarded as the native device group identifier for that device group. This approach allows upstream business systems using the AWS platform to use a simple "key" to identify groups, just like when using other IoT platforms (i.e., platforms that support key systems), greatly simplifying the development logic of upper-layer applications. Figure 5 It provides a detailed demonstration of the generation and binding relationship between AWS pre-built certificate templates and virtual group keys.

[0049] S206: Generate a global device group identifier for the device group, and establish a first mapping relationship between the global device group identifier and the native device group identifier, so that the upstream business system can perform IoT control on the IoT devices belonging to the device group through the target platform instance based on the first mapping relationship.

[0050] After acquiring or generating the underlying native identifier, the unified management system can generate a unique global device group identifier (e.g., a trust Product Key). This global device group identifier is independent of the underlying IoT platform and is a uniquely visible identifier to the upstream business system. The unified management system stores the global device group identifier in correspondence with the native device group identifiers determined in step S203 (e.g., Alibaba Cloud's Product Key and AWS's virtual group key). Figure 1The mapping engine module (as shown) establishes the first mapping relationship. This first mapping relationship is typically stored in a high-performance key-value database or relational database for quick retrieval when subsequent control commands are issued. Through this mapping layer, upstream business systems only need to hold the global device group identifier to indirectly operate any type of underlying IoT platform through the unified management system, achieving complete decoupling between business logic and the underlying IoT platform implementation.

[0051] After creating and mapping device groups, upstream business systems typically need to define and control parameters for the devices within the group. However, the field names of object models differ significantly across platforms, and direct pass-through can lead to incompatibility issues for upper-layer applications. Therefore, this specification also provides a parameter name alignment and control method, such as... Figure 3 As shown.

[0052] Figure 3 A flowchart illustrating the parameter name alignment and downlink control method provided in this specification. This method includes the following steps: S300: Obtain the parameter name of the configuration parameter for the device group by the upstream business system, and use it as the parameter name corresponding to the upstream business system; and obtain the parameter name of the native parameter supported by the target platform, and use it as the parameter name corresponding to the target platform; establish the correspondence between the parameter name corresponding to the upstream business system and the parameter name corresponding to the target platform, and save it.

[0053] In this step, the upstream business system submits a standard object model definition to the unified management system. This definition includes a set of standardized attribute names (e.g., temperature, humidity) and instruction names (e.g., switch_on, set_brightness). After receiving these standard names, the unified management system retrieves the native parameter names supported by the target platform based on the platform type of the target platform to which the device group belongs.

[0054] For example, for Alibaba Cloud, the native field names can be obtained by querying its Thing Specification Language (TSL) definition; for AWS, it is necessary to parse its Device Shadow JSON structure or customize mapping rules.

[0055] Subsequently, the unified management system can establish a mapping table between standard names and native names and persist it.

[0056] For example, create mapping: { "temperature": "Current Temperature" (Aliyun), "state.reported.temp" (AWS)}.

[0057] S302: Receive the control request sent by the upstream business system; parse out the control parameters carried in the control request.

[0058] When an upstream business system needs to issue control commands, it can send a control request to the unified management system. This control request contains a global device group identifier, a target device identifier (described in detail later), and control parameters. The control parameters use standard parameter names defined in S300. For example, the request might contain { "device_id": "dev_001","params": { "temperature": 25}}. The unified management system parses the control request and extracts the standard parameter name "temperature" and its value 25.

[0059] S304: Determine the native device group identifier based on the global device group identifier and the first mapping relationship, and determine the parameter name of the control parameter on the target platform based on the correspondence relationship and the parameter name of the control parameter in the upstream business system.

[0060] The unified management system first uses the global device group identifier in the control request to query the first mapping relationship and find the corresponding native device group identifier (e.g., the Product Key or virtual group key determined in step S204). Next, based on this native device group identifier, the unified management system determines the platform type of the IoT platform to which it belongs and loads the parameter name mapping relationship established in step S300. The unified management system searches for the native parameter name "temperature" under the target platform. If the target platform is Alibaba Cloud, it is determined to be "CurrentTemperature"; if it is AWS, it is determined to be "state.reported.temp". This step achieves a dynamic conversion from unified semantics to platform-specific semantics.

[0061] S306: Based on the parameter name corresponding to the control parameter on the target platform and the native device group identifier, generate a control command to perform IoT control on IoT devices belonging to the device group through the target platform instance based on the control command.

[0062] Finally, the unified management system uses the converted native parameter names and original parameter values ​​to construct control instructions that conform to the target platform's API specifications.

[0063] For example, for Alibaba Cloud, a JSON payload in the Alink protocol format is constructed; for AWS, an input structure for UpdateThing Shadow is built. The platform connector sends this control command to the underlying IoT platform, ultimately reaching the IoT device that needs to be controlled. Through this process, upstream business systems do not need to know which IoT platform is underway; they only need to send control requests in a standard format to achieve unified control across platforms.

[0064] The above embodiments mainly describe device group-level management and parameter alignment. In practical applications, IoT control often needs to be precise down to the individual device level. Therefore, this specification provides a device registration and control method based on a global device identifier, such as... Figure 4 As shown.

[0065] Figure 4 This is a flowchart of the device registration and global identifier mapping method provided in this specification. The method includes the following steps: S400: Receive a device registration request from the upstream business system, the device registration request carrying the global device group identifier.

[0066] In this step, after creating the device group (product), the upstream business system needs to register specific physical or virtual device instances under that device group. The upstream business system sends a device registration request, which must include the global device group identifier (trust Product Key) generated in S206. In addition, the device registration request may also include metadata such as the device's serial number, MAC address, and firmware version. Upon receiving the device registration request, the unified management system first verifies the validity of the global device group identifier to confirm that the device group exists in the unified management system and is active.

[0067] S402: Based on the first mapping relationship, determine the native device group identifier corresponding to the global device group identifier and the target platform instance.

[0068] The unified management system can query the initial mapping relationship established in step S206. Using the global device group identifier, the unified management system reversely retrieves the corresponding native device group identifier (e.g., Alibaba Cloud's Product Key or AWS's Virtual Group Key) and the target platform instance information to which the group belongs (e.g., Endpoint, Region, Connector Type). This step ensures that subsequent device registration operations are accurately routed to the correct underlying IoT platform instance.

[0069] S404: Invoke the platform connector corresponding to the target platform instance, register at least one device in the device group in the target platform instance, and obtain the native device identifier corresponding to the registered device.

[0070] The platform connector executes specific device registration logic based on the target platform type determined in step S402. Because device registration mechanisms differ across platforms, this step employs different implementation methods for platforms with different authentication types.

[0071] For key-based authentication platforms (such as Alibaba Cloud and Tuya), the connector directly calls the underlying device creation interface (such as Alibaba Cloud's Register Device). After verifying the validity of the Product Key, the underlying IoT platform assigns a unique Device Name and Device Secret to the device. At this point, the unified management system returns the Device Name or DeviceID as the native device identifier.

[0072] However, for certificate-based authentication platforms (such as AWS IoT Core), the traditional static certificate distribution model suffers from efficiency bottlenecks and security risks in large-scale production testing scenarios. To overcome this deficiency, this manual adopts a batch pre-registration mechanism based on pre-built templates.

[0073] Specifically, if the target platform is a certificate-based IoT platform, the unified management system initiates a device pre-registration request using a pre-configured certificate template associated with the native device group identifier. Subsequently, the unified management system receives the device certificate identifier or activation token returned by the underlying IoT platform and uses it as the native device identifier.

[0074] Taking AWS as an example, in this process, the unified management system, based on the platform connector, first utilizes the binding relationship established in step S204 to find the corresponding AWS pre-built certificate template ARN through the virtual group key. Then, it calls AWS's CreateKeys And Certificate or Register Thing interface, combined with the pre-built template policy, to generate the device's X.509 certificate private key pair or activation token. The Certificate ARN or Thing Name returned by AWS serves as the native device identifier. This mechanism allows the device to only possess an activation token at the factory, and dynamically obtain a certificate upon first network connection, greatly simplifying the entire process and improving security.

[0075] Especially in large-scale product testing scenarios, the platform connector can call AWS's bulk registration interface to generate activation tokens for tens of thousands of devices at once. After the unified management system receives the returned bulk results, it asynchronously creates the corresponding global device identifiers and mapping relationships in the database, thereby supporting the rapid deployment of massive numbers of devices.

[0076] S406: Generate a global device identifier for the registered device and establish a second mapping relationship between the global device identifier and the native device identifier; return the global device identifier to the upstream business system.

[0077] After obtaining the native device identifier returned by the underlying IoT platform, the unified management system generates a unique global device identifier (trust Device ID). This identifier serves as a unique credential for upstream business systems to identify individual devices, decoupled from the Device Name or Certificate ID of the underlying IoT platform. The unified management system stores the global device identifier and the native device identifier in a database, establishing a second mapping relationship. Finally, the unified management system returns the global device identifier to the upstream business system. At this point, the device is registered in the unified management system, and the upstream business system can use the global device identifier for subsequent command issuance or status queries.

[0078] To achieve a consistent development experience with the key platform and avoid upstream business systems dealing with complex certificate files, this specification further provides a mechanism for generating virtual device keys.

[0079] Specifically, the unified management system can generate virtual device keys and establish a mapping relationship between virtual device keys and device certificate identifiers or activation tokens. Then, the virtual device key is returned to the upstream business system as part of the global device identifier or associated credential, so that the upstream business system can use a unified key format for subsequent device management.

[0080] The unified management system can generate a random string as a virtual device key and map it to the certificate ARN or activation token returned by AWS (i.e., the mapping relationship mentioned above). When upstream business systems need to perform device authentication or signature verification, they can use this virtual device key, which the unified management system will convert into an actual certificate in the background for underlying interaction. This approach shields the complexity of certificate management, making device credential management in multi-IoT platform environments more standardized.

[0081] After device registration is completed, upstream business systems can precisely control specific devices using global device identifiers. At this point, the control request includes not only the global device group identifier but also the global device identifier of the device to be controlled.

[0082] The unified management system first determines the native device identifier corresponding to the global device identifier based on the second mapping relationship mentioned above, and simultaneously determines the native device group identifier corresponding to the global device group identifier based on the first mapping relationship. Then, the unified management system, combining the parameter name conversion logic described below, generates control commands containing the native device identifier and native parameter format, and sends them to the underlying target platform through the platform connector. This two-layer mapping mechanism (group mapping + device mapping) ensures that control commands can be accurately routed to specific physical devices.

[0083] It is important to note that the "correspondence" established in the aforementioned S300 step is not a simple string replacement, but a structured mapping based on the "Standard Thing Model" defined in this specification. Because the thing model definition systems of different underlying IoT platforms differ fundamentally—for example, Alibaba Cloud IoT uses a JSON structure (ThingSpecification Language) containing three dimensions: Property, Service, and Event, with metadata such as data type, value range, and read / write permissions for each dimension; while AWS IoT Core primarily stores state through JSON documents of Device Shadows, lacking native service call definitions; and Tuya Smart uses a Data Point (DP) mechanism, mapping function points through IDs.

[0084] To address these structural differences, this specification defines a neutral standard object model format within the unified management system. This standard format abstracts the commonalities across all platforms, including standardized attribute identifiers, service identifiers, event identifiers, and corresponding data types (such as integers, floating-point numbers, booleans, enumerations, structures, etc.).

[0085] In practical implementation, when the upstream business system configures the standard object model, the unified management system (such as through...) Figure 1 The object model engine module 1023 shown executes the following transformation logic, such as Figure 5 As shown.

[0086] Figure 5 This is a schematic diagram illustrating the process of converting a standard object model into an object model supported by the underlying IoT platform, as provided in this specification.

[0087] First, parse the standard object model definition submitted from upstream and extract its attribute list. For example, the standard attribute "brightness" is defined as an integer type, ranging from 0 to 100.

[0088] Secondly, based on the target platform's platform type, obtain the original biological model metadata for that target platform. For example, for Alibaba Cloud, the unified management system queries the TSL definition under the Product Key, finds the corresponding "Bright Ness" attribute, and confirms that its data type is Integer, ranging from 0 to 1000 (assuming the underlying definition is different); as another example, for AWS, the unified management system may need to predefine a JSON path in the device shadow, such as "state.desired.brightness".

[0089] Then, establish multi-dimensional mapping relationships. This includes not only mapping field names (such as "brightness" -> "Bright Ness"), but also "normalization mapping of data values".

[0090] For example, if the underlying Alibaba Cloud defines the brightness range as 0-1000, while the standard model defines it as 0-100, the object model engine module 1023 can record a linear transformation rule: $V_{std} = V_{native} / 10$. (This formula is only an example; in actual implementation, multiple transformation algorithms such as linear and lookup tables can be supported.)

[0091] Finally, the above name mapping and value conversion rules are saved to storage module 1024. During downlink control (i.e., step S304), the unified management system not only converts the parameter name, but also converts the standard value (e.g., 50) sent from the upstream to the native value (e.g., 500) required by the target platform at the bottom layer according to the conversion rules; during uplink data processing (i.e., step S603 mentioned later), the unified management system converts the native value (e.g., 800) reported by the bottom layer back to the standard value (80) and sends it to the upstream business system.

[0092] Through this deep object model mapping mechanism, this specification not only achieves interface-level unification but also true standardization at the semantic and data levels. Upstream business systems do not need to care whether the underlying protocol is Alink, Tuya Link, or AWS Device Shadow; they only need to develop based on the standard object model to achieve seamless cross-platform interaction.

[0093] To achieve a closed-loop two-way communication system, enabling upstream business systems to monitor device status in real time, this manual further provides the upstream data processing flow, such as... Figure 6 As shown.

[0094] Figure 6 This is a flowchart of the uplink data processing and status synchronization method provided in this specification. The method includes the following steps: S600: Receive uplink update information from the target platform, wherein the uplink update message carries the native device identifier of the target device with updated status.

[0095] After receiving status data (such as temperature changes or on / off status changes) reported by the device, the underlying IoT platform sends an uplink update message to the unified management system via methods such as MQTT Topic callback, HTTP Push, or Stream Processing. This message may contain the target device's native device identifier (such as Device Name or Thing Name) and its native status data.

[0096] The unified management system's message access module listens to these message channels with various IoT platforms to capture uplink messages in real time. Among these, the platform connectors not only support HTTP API calls but also encapsulate protocol adaptation logic for different platforms, such as MQTT and CoAP. For example, for devices supporting MQTT direct connection, the connector can proxy and forward MQTT messages, performing protocol payload conversion during the forwarding process (such as converting Alibaba Cloud's Alink JSON to standard JSON).

[0097] S602: Determine the global device identifier corresponding to the target device based on the second mapping relationship.

[0098] The unified management system extracts the native device identifier from the uplink update information and queries the second mapping relationship. Through reverse retrieval, the unified management system finds the global device identifier (trust Device ID) bound to the native device identifier and the global device group identifier to which it belongs. This step realizes the identity conversion from the "bottom layer perspective" to the "upper layer perspective," enabling subsequent business logic processing to be based on the unified global identifier, without needing to know which IoT platform the device is actually connected to.

[0099] S604: Based on the global device identifier corresponding to the target device, send a status update message for the target device to the upstream business system.

[0100] After determining the global device identifier, the unified management system standardizes the raw status data. If the parameter name correspondence and value conversion rules are established in step S300, the unified management system can also use this relationship to convert the raw parameter names (such as "Current Temperature") in the data into standard parameter names (such as "temperature"), and convert the raw values ​​into standard values.

[0101] Ultimately, the unified management system constructs a status update message containing a global device identifier, standard parameter names, and data values, and sends it to the upstream business system via API callbacks or message queues. For example, it sends { "device_id": "trustDev_001", "params": { "temperature": 25.5}}. Through this process, all device data received by the upstream business system has a unified format and identifier, greatly simplifying the logic of data storage, analysis, and display.

[0102] In summary, this specification achieves transparent management of heterogeneous IoT platforms by establishing a two-layer mapping relationship (group level and device level) between global and native identifiers, combined with a deep conversion mechanism for parameter names and values. Whether it's a key-based or certificate-based IoT platform, upstream business systems can complete device creation, registration, control, and data reception through a unified API interface, truly enabling unified access to various IoT platforms and unified management of devices across different IoT platforms.

[0103] Figure 7 This is a schematic structural diagram of a device provided in this manual. Please refer to it. Figure 7 At the hardware level, the device includes a processor 702, an internal bus 704, a network interface 706, memory 708, and non-volatile memory 710, and may also include other hardware required for its functions. One or more embodiments of this specification can be implemented in software, for example, the processor 702 reads the corresponding computer program from the non-volatile memory 710 into memory 708 and then runs it. Of course, in addition to software implementation, one or more embodiments of this specification do not exclude other implementation methods, such as logic devices or a combination of hardware and software, etc. That is to say, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0104] Please refer to Figure 8 This specification provides a device for unified management of devices across multiple IoT platforms, which can be applied to, for example... Figure 7 The device shown is used to implement the technical solution of this specification. The device may include: The receiving module 800 receives an access request from an upstream business system for a group of devices to be managed. The access request includes: the platform type of the IoT platform that manages the group of devices, and the group of devices contains at least one IoT device. The determination module 802 determines the target platform for managing the device group based on the platform type. Module 804 is invoked to invoke the platform connector of the target platform to allocate a target platform instance for managing the device group in the target platform, and to determine the native device group identifier of the device group under the target platform instance; The generation module 806 generates a global device group identifier for the device group and establishes a first mapping relationship between the global device group identifier and the native device group identifier, so that the upstream business system can perform IoT control on the IoT devices belonging to the device group through the target platform instance based on the first mapping relationship.

[0105] Optionally, the calling module 804 is specifically configured to: if the target platform is a key-based IoT platform, obtain the configuration information of the target platform instance, the configuration information including: the access credentials corresponding to the target platform instance and the access address corresponding to the target platform instance; initiate a creation request using the configuration information through the platform connector to create a device group identifier for the target platform instance for the device group; and receive the returned device group identifier to use the device group identifier as the native device group identifier.

[0106] Optionally, the calling module 804 is specifically configured to: if the target platform is a certificate-based IoT platform, obtain the configuration information of the target platform instance, the configuration information including: the access address corresponding to the target platform instance and the authentication parameters corresponding to the target platform instance; send a creation request through the platform connector using the configuration information to create a preset certificate template identifier for the target platform instance for the device group; receive the returned preset certificate template identifier, and generate the native device group identifier based on the preset certificate template identifier.

[0107] Optionally, the calling module 804 is specifically used to generate a virtual group key bound to the preset certificate template identifier; and to use the virtual group key as the native device group identifier.

[0108] Optionally, the receiving module 800 is further configured to: obtain the parameter name of the configuration parameter of the upstream business system for the device group, as the parameter name corresponding to the upstream business system; and obtain the parameter name of the native parameter supported by the target platform, as the parameter name corresponding to the target platform. The generation module 806 is further configured to establish and save the correspondence between the parameter names corresponding to the upstream business system and the parameter names corresponding to the target platform. The receiving module 800 is further configured to: receive a control request sent by the upstream business system; parse out the control parameters carried in the control request; determine the native device group identifier based on the global device group identifier and the first mapping relationship; and determine the parameter name corresponding to the control parameter on the target platform based on the correspondence relationship and the parameter name corresponding to the control parameter in the upstream business system. The generation module 806 is further configured to generate control instructions based on the parameter name corresponding to the control parameters on the target platform and the native device group identifier, so as to perform IoT control on IoT devices belonging to the device group through the target platform instance based on the control instructions.

[0109] Optionally, the receiving module 800 is further configured to receive a device registration request from the upstream business system, the device registration request carrying the global device group identifier; and determine the native device group identifier corresponding to the global device group identifier and the target platform instance according to the first mapping relationship; The calling module 804 is further configured to call the platform connector corresponding to the target platform instance, register at least one device in the device group in the target platform instance, and obtain the native device identifier corresponding to the registered device; The generation module 806 is further configured to generate a global device identifier for the registered device, and establish a second mapping relationship between the global device identifier and the native device identifier; and return the global device identifier to the upstream business system. The receiving module 800 is further configured to receive a control request sent by the upstream business system, wherein the control request carries a global device group identifier of the device group to which the device to be controlled belongs and a global device identifier of the device to be controlled; and determine the native device group identifier corresponding to the device to be controlled and the native device identifier corresponding to the device to be controlled according to the first mapping relationship and the second mapping relationship. The generation module 806 is further configured to generate control commands based on the native device group identifier corresponding to the device to be controlled and the native device identifier corresponding to the device to be controlled, so as to perform IoT control on the device to be controlled through the target platform instance based on the control commands.

[0110] Optionally, the receiving module 800 is further configured to: receive uplink update information from the target platform, wherein the uplink update message carries the native device identifier of the target device whose status is updated; determine the global device identifier corresponding to the target device according to the second mapping relationship; and send a status update message for the target device to the upstream business system based on the global device identifier corresponding to the target device.

[0111] Based on the same concept as the methods described above, this specification also provides an electronic device, including: a processor; a memory for storing processor-executable instructions; wherein the processor performs the steps of the method as described in any of the above embodiments by executing the executable instructions.

[0112] Based on the same concept as the methods described above, this specification also provides a computer-readable storage medium having computer instructions stored thereon that, when executed by a processor, implement the steps of the methods as described in any of the above embodiments.

[0113] Based on the same concept as the methods described above, this specification also provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the methods as described in any of the above embodiments.

[0114] This specification can be described in the general context of computer-executable instructions that are executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a specific task or implement a specific abstract data type. This specification can also be practiced in distributed computing environments, where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0115] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0116] The above are merely embodiments of this specification and are not intended to limit this specification. Various modifications and variations can be made to this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims of this specification.

Claims

1. A method for unified management of devices across multiple IoT platforms, the method being applied in a management system, the method comprising: Receive an access request from an upstream business system for a group of devices to be managed. The access request includes: the platform type of the IoT platform that manages the group of devices, and the group of devices contains at least one IoT device. Based on the platform type, determine the target platform for managing the device group; Invoke the platform connector of the target platform to allocate a target platform instance for managing the device group in the target platform, and determine the native device group identifier of the device group under the target platform instance; A global device group identifier is generated for the device group, and a first mapping relationship is established between the global device group identifier and the native device group identifier, so that the upstream business system can perform IoT control on the IoT devices belonging to the device group through the target platform instance based on the first mapping relationship.

2. The method of claim 1, wherein determining the native device group identifier of the device group under the target platform instance includes: If the target platform is a key-based IoT platform, obtain the configuration information of the target platform instance. The configuration information includes: the access credentials corresponding to the target platform instance and the access address corresponding to the target platform instance. Through the platform connector, a creation request is initiated using the configuration information to create a device group identifier for the target platform instance targeting the device group; Receive the returned device group identifier, and use the device group identifier as the native device group identifier.

3. The method of claim 1, wherein determining the native device group identifier of the device group under the target platform instance includes: If the target platform is a certificate-based IoT platform, obtain the configuration information of the target platform instance. The configuration information includes: the access address corresponding to the target platform instance and the authentication parameters corresponding to the target platform instance. Through the platform connector, a creation request is sent using the configuration information to create a pre-defined certificate template identifier for the target platform instance for the device group; Receive the returned pre-set certificate template identifier, and generate the native device group identifier based on the pre-set certificate template identifier.

4. The method as described in claim 3, wherein generating the native device group identifier based on the preset certificate template identifier includes: Generate a virtual group key that is bound to the preset certificate template identifier; The virtual group key is used as the native device group identifier.

5. The method of claim 1, further comprising: Obtain the parameter name of the configuration parameter for the device group by the upstream business system, and use it as the parameter name corresponding to the upstream business system; and obtain the parameter name of the native parameter supported by the target platform, and use it as the parameter name corresponding to the target platform. Establish and save the correspondence between the parameter names in the upstream business system and the parameter names in the target platform; The method further includes: Receive control requests sent by the upstream business system; Parse the control parameters carried in the control request; Based on the global device group identifier and the first mapping relationship, the native device group identifier is determined, and based on the correspondence relationship and the parameter name corresponding to the control parameter in the upstream business system, the parameter name corresponding to the control parameter in the target platform is determined; Based on the parameter name corresponding to the control parameters on the target platform and the native device group identifier, a control command is generated to perform IoT control on IoT devices belonging to the device group through the target platform instance based on the control command.

6. The method of claim 1, further comprising: Receive a device registration request from the upstream business system, the device registration request carrying the global device group identifier; Based on the first mapping relationship, determine the native device group identifier corresponding to the global device group identifier and the target platform instance; Invoke the platform connector corresponding to the target platform instance, register at least one device in the device group in the target platform instance, and obtain the native device identifier corresponding to the registered device; Generate a global device identifier for the registered device, and establish a second mapping relationship between the global device identifier and the native device identifier; The global device identifier is returned to the upstream business system; The method further includes: Receive a control request sent by the upstream business system. The control request carries the global device group identifier of the device group to which the device to be controlled belongs and the global device identifier of the device to be controlled. Based on the first mapping relationship and the second mapping relationship, determine the native device group identifier corresponding to the device to be controlled, and the native device identifier corresponding to the device to be controlled; Based on the native device group identifier and the native device identifier corresponding to the device to be controlled, a control command is generated to perform IoT control on the device to be controlled through the target platform instance based on the control command.

7. The method of claim 6, further comprising: Receive uplink update information from the target platform, wherein the uplink update message carries the native device identifier of the target device with updated status; Based on the second mapping relationship, determine the global device identifier corresponding to the target device; Based on the global device identifier corresponding to the target device, a status update message for the target device is sent to the upstream business system.

8. An electronic device, comprising: processor; A memory for storing processor-executable instructions; wherein the processor implements the steps of the method as described in any one of claims 1 to 7 by executing the executable instructions.

9. A computer-readable storage medium having stored thereon computer instructions that, when executed by a processor, implement the steps of the method as claimed in any one of claims 1 to 7.

10. A computer program product comprising a computer program / instructions that, when executed by a processor, implement the steps of the method as claimed in any one of claims 1 to 7.

Images