Matter equipment automatic test method and system based on cloud edge collaboration

Abstract

The invention provides a Matter equipment automatic testing method and system based on cloud edge collaboration, and belongs to the technical field of Internet of Things equipment testing. The method aims at solving the problems that in the prior art, Matter equipment production testing depends on manual work, efficiency is low, burning and testing processes are disjointed, and missing detection risks exist. The method comprises the steps that a cloud service creates and distributes burning batches and test cases; the burning client obtains the task from the edge service, carries out burning on the Matter equipment and reports a result; after receiving the burning result, the edge service automatically triggers a test agent to test the equipment; and the test agent executes the test and reports a result to the edge service. The invention also provides a system for realizing the method. According to the method and the device, automatic closed loop of burning and testing processes is realized, 'burning is testing 'is realized, the risk of missing detection is avoided, and the testing efficiency, the standard uniformity and the system expansibility are improved by utilizing the cloud edge collaborative architecture.

Description

Technical Field

[0001] This application relates to the field of IoT device testing technology, and in particular to an automated testing method and system for smart home devices supporting the Matter protocol during the production process. Background Technology

[0002] The Matter protocol, as an emerging unified application layer standard for interconnectivity between smart home devices, aims to solve compatibility issues between different brands and ecosystems. To ensure product quality and user experience, all devices conforming to the Matter protocol must undergo rigorous quality verification before leaving the factory, especially verifying the correctness of the device firmware and the device authentication certificate that serves as the device's identity credential.

[0003] In existing technologies, production testing of Matter devices primarily relies on officially provided command-line tools or test suites. Production line operators typically need to manually execute test commands, performing individual or sample testing on each device. This approach has several significant drawbacks: First, manual operation is inefficient, prone to human error due to operator fatigue or negligence, and fails to meet the demands of large-scale, high-paced modern production. Second, test cases and related configurations are usually scattered across various test terminals, lacking a unified version management and distribution mechanism. This can lead to inconsistent testing standards across different production lines or batches, affecting product quality stability. Finally, and most critically, the firmware and certificate burning process and subsequent functional testing are usually two independent stages, lacking an effective automated linkage mechanism. This disconnect not only increases operational complexity but also introduces a high risk of missed detections. If devices with incorrectly burned firmware or certificates fail to be detected in time and enter the market, they will be unable to properly network and function, leading to serious product quality incidents and high after-sales recall costs.

[0004] To address some of the aforementioned issues, one technical solution proposes using a central control device to drive terminal devices, enabling automated testing after programming. However, this centralized control architecture faces bottlenecks in system scalability, task distribution efficiency, and network communication latency when dealing with multiple production lines and large-scale deployments, making it difficult to flexibly and efficiently support modern distributed production models. Summary of the Invention

[0005] The purpose of this application is to provide an automated testing method and system for Matter devices based on cloud-edge collaboration, in order to solve the technical problems in the existing technology of Matter device production testing, such as reliance on manual operation, low efficiency, inconsistent testing standards, disconnect between programming and testing processes, risk of missed detection, and insufficient scalability of centralized control architecture.

[0006] In a first aspect, embodiments of this application provide an automated testing method for Matter devices based on cloud-edge collaboration, which includes the following steps:

[0007] Step 1: The cloud service creates a flashing batch containing firmware and certificate information and configures test cases associated with the flashing batch; the cloud service synchronizes the flashing batch to the edge service and the test cases to the test agent;

[0008] Step 2: The programming client obtains the programming batch information from the edge service, performs the programming operation on the Matter device, and notifies the edge service of the programming result after the programming is completed;

[0009] Step 3: After receiving the burning result, the edge service automatically triggers the test agent to start automated testing on the Matter device that has completed the burning process;

[0010] Step 4: The test agent parses the test case, pairs with the Matter device and executes the test, and reports the test results to the edge service.

[0011] Optionally, after step one, the method further includes:

[0012] After receiving the test case, the test agent caches the test case locally for use when it is triggered.

[0013] Optionally, in step two, before the burning client performs the burning operation on the Matter device, the method further includes:

[0014] The programming client sends a request to the edge service to issue a device authentication certificate for the Matter device.

[0015] Optionally, at least one of the following may be included:

[0016] The programming client supports parallel programming of multiple Matter devices;

[0017] The test agent supports parallel testing of multiple Matter devices.

[0018] Optionally, the method further includes at least one of the following:

[0019] Before the test agent receives the test task, it performs a local environment self-check and reports an error if the self-check is abnormal.

[0020] If the burning operation or test fails, a preset retry operation is performed.

[0021] Optionally, after step four, the method further includes:

[0022] The edge service collects and reports the test results to the cloud service;

[0023] The cloud service updates the status of the burning batch and generates a test report based on the test results.

[0024] Secondly, embodiments of this application also provide an automated testing system for Matter devices based on cloud-edge collaboration, comprising:

[0025] The cloud service is used to create flashing batches containing firmware and certificate information, configure test cases associated with the flashing batches, synchronize the flashing batches to the edge service, and synchronize the test cases to the test agent.

[0026] The programming client is used to obtain the programming batch information from the edge service, perform programming operations on the Matter device, and notify the edge service of the programming results after programming is completed.

[0027] The test agent is used to receive and parse the test cases, pair with the Matter device and execute the test after being triggered, and report the test results to the edge service.

[0028] An edge service is used to receive the burning batch from the cloud service, provide the burning batch information to the burning client, and automatically trigger the test agent to start automated testing on the Matter device that has completed burning after receiving the burning result reported by the burning client.

[0029] Compared with the prior art, this application has the following beneficial effects:

[0030] 1. Seamless automated integration of programming and testing has been achieved. After receiving the programming result, the edge service automatically triggers the test agent, connecting the two originally independent links into a closed-loop automated process, realizing "programming is testing", and fundamentally eliminating the risk of human oversight or missed detection caused by process disconnection.

[0031] 2. It ensures the uniformity and reliability of testing standards. Test cases are centrally managed and uniformly distributed by cloud services, ensuring that all test agents in the production site use the same set of standards for testing, avoiding product quality fluctuations caused by inconsistent test case versions, and improving the traceability of test results.

[0032] 3. Enhanced system scalability and flexibility: Based on the distributed collaborative architecture of "cloud-edge-device", edge services and test nodes can be easily deployed on demand in different production lines and managed uniformly through the cloud. The system has good scalability and can meet the needs of large-scale production.

[0033] 4. Significantly improves production and testing efficiency. Automated processes replace cumbersome manual operations and support parallel programming and parallel testing, greatly increasing the throughput of the production line. Attached Figure Description

[0034] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. Furthermore, these drawings and textual descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concepts of this application to those skilled in the art through reference to specific embodiments.

[0035] Figure 1 A schematic diagram of the architecture of a Matter device automated testing system based on cloud-edge collaboration is provided for an embodiment of this application;

[0036] Figure 2 A flowchart illustrating an automated testing method for Matter devices based on cloud-edge collaboration, provided as an embodiment of this application;

[0037] Figure 3 This is a timing diagram of an integrated production, programming, and testing process according to one embodiment of this application;

[0038] Figure 4 This is a timing diagram of an automated test process for an independent function, according to another embodiment of this application. Detailed Implementation

[0039] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions in the embodiments of this application will be clearly and completely described below in conjunction with the embodiments of this application. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application. Unless otherwise specified, the following embodiments and features can be combined with each other.

[0040] Example 1

[0041] This embodiment provides a basic implementation scheme for a cloud-edge collaborative automated testing method and system for Matter devices, aiming to elaborate in detail how to achieve a fully automated closed-loop process from programming to testing in a typical production line environment.

[0042] Please see Figure 1 This document illustrates a schematic diagram of the overall architecture of an automated testing system according to an embodiment of this application. The system adopts a distributed architecture with cloud-edge collaboration, primarily comprising a cloud service 10 located in the cloud, and an edge service 20, a programming client 30, a test agent 40, and a Matter device 50 deployed in edge environments such as production sites. The cloud service 10 and the edge service 20 exchange data via a stable and reliable network communication protocol. For example, a lightweight message queue telemetry transmission protocol can be used to achieve asynchronous message communication via an MQTT communication bus 60, enabling task distribution and result aggregation. At the edge, the edge service 20 acts as the on-site command center, responsible for receiving macro-level tasks from the cloud service 10 and performing specific scheduling and coordinated control of the local programming client 30 and test agent 40. The programming client 30 is the entity that performs the physical programming operation, while the test agent 40 is the entity that performs automated testing; both work together on the Matter device 50.

[0043] Please refer to the following: Figure 2 and Figure 3 , Figure 2 This is a general flowchart of the method provided in the embodiments of this application. Figure 3 This is a sequence diagram showing the interactions between the entities in this embodiment. The specific steps of this integrated process will be described in detail below.

[0044] The process can be divided into three main stages: the pre-configuration stage, the burning and linkage triggering stage, and the automated testing and result reporting stage.

[0045] The first phase is pre-configuration and task distribution, which corresponds to... Figure 2 In step S101, the cloud service creates a burning batch containing firmware and certificate information and configures test cases associated with the burning batch; the cloud service synchronizes the burning batch to the edge service and synchronizes the test cases to the test agent.

[0046] In a specific application scenario, a production line administrator or product manager needs to assign production tasks to a new batch of Matter devices 50. The administrator accesses a web interface provided by cloud service 10 through a browser. Cloud service 10 can be a backend application consisting of multiple microservices deployed on a public or private cloud server, providing functions including user authentication, resource management, task scheduling, and data analysis.

[0047] The administrator performs the "Create Burning Batch" operation on the interface. The system then displays a form requiring the administrator to enter batch-related information, such as the batch name (e.g., "Smart Socket SP-101-20241026 Batch"), planned production quantity, and product model. Next, the administrator uses a file upload control to upload the firmware binary file (e.g., firmware_v1.2.bin) used by this batch of products to the cloud service's storage system (e.g., object storage service). Simultaneously, the certificate information required for this batch, such as intermediate product certification certificates and certification statements, is also associated with this batch.

[0048] A crucial step involves the administrator configuring a set of associated test cases for the batch of devices being burned. Cloud Service 10 provides a test case library with various pre-stored test scripts. Administrators can select one or more suitable test cases, such as a test suite named "Factory Basic Function Verification." This test suite may include tests verifying whether the device can enter network configuration mode normally, whether it can be successfully paired, and whether core functions (such as switching and dimming) respond normally.

[0049] After configuration, the backend logic of cloud service 10 immediately executes task distribution. Specifically, it constructs a task message from the core information of the batch being burned, including the batch ID, firmware download address, associated certificate information, and an identifier pointing to the selected use case. This message is published to a specific topic, such as factory / line1 / edge / tasks, via the MQTT communication bus 60. Edge service 20, deployed locally on the production line, is able to receive this new batch information in near real-time because it has subscribed to this topic, and stores it in its local database for later use.

[0050] Meanwhile, cloud service 10 also publishes the complete test cases associated with this batch (which can be a structured JSON or YAML file, defining the test steps, parameters, and expected results in detail) to another topic, such as factory / line1 / proxies / testcases, via MQTT communication bus 60. All test agents 40 located in this production line subscribe to this topic. When test agent 40 receives new test cases, it performs a local caching operation. Specifically, test agent 40 stores the received test case files in local non-volatile storage (e.g., solid-state drive), using the test case ID as the filename or index. It should be noted that this local caching mechanism ensures that test agent 40 does not need to request test cases from the cloud again when executing tests subsequently, thereby greatly reducing the latency of test startup and enhancing the robustness of the system under unstable network conditions.

[0051] The second stage involves device programming and automated linkage triggering, which corresponds to... Figure 2 Steps S102, S103, and S104 in the process. That is, the programming client obtains the programming batch information from the edge service, performs the programming operation on the Matter device, and notifies the edge service of the programming result after the programming is completed; after receiving the programming result, the edge service automatically triggers the test agent to start automated testing on the Matter device that has completed programming.

[0052] On the production line, one or more computers are deployed at the programming station, running programming clients 30. The programming client 30 can be a desktop application that connects to the programming fixture via a physical interface (such as JTAG or SWD). The fixture can simultaneously connect to one or more Matter devices 50 to be programmed.

[0053] After the programming client 30 starts, it actively sends a task request to the local edge service 20. This request can be implemented through HTTP polling, that is, the programming client 30 periodically sends requests to a certain API endpoint of the edge service 20 (e.g., http: / / <edge-server-ip>The edge service 20 sends a request via :8080 / get-task. Upon receiving the request, the edge service 20 queries its local database for information on currently active burning batches and returns it to the burning client 30.

[0054] A production line worker places a brand-new Matter device 50 onto the programming fixture. Once the programming client 30 detects the device is in place, it begins the programming process. Specifically, it first reads the device's unique identifier, typically the MAC address of its Wi-Fi or Bluetooth module; then it performs the programming operation. This operation is a complex process, including writing the firmware binary file obtained from the cloud service 10 into the flash memory of the Matter device 50's main control chip, writing the intermediate product certification certificate and certification statement corresponding to the product model into a specific storage area of ​​the device, and generating and writing a unique device certification certificate for the device. The method for generating the device certification certificate will be detailed in subsequent embodiments.

[0055] After the programming operation is complete, the programming client 30 performs a quick verification, such as reading a portion of the data in the flash memory and comparing it with the source file to confirm the correctness of the write. Once confirmed, the programming client 30 immediately reports the programming result to the edge service 20. This reporting operation can be a single call to a specific API endpoint (e.g., http: / / <edge-server-ip>An HTTP POST request (e.g., :8080 / report-burn-status) contains key information in its request body, which can be in the format of a JSON object, for example: {"device_id":"XX:XX:XX:XX:XX:XX","batch_id":"SP-101-20241026","status":"success","timestamp":"2024-10-26T14:30:05Z"}.

[0056] Upon receiving the "burning successful" notification, the edge service 20 triggers its core automated linkage mechanism, crucial for seamless integration between the burning and testing phases. The edge service 20 maintains a pre-defined linkage logic rule defining that "when a successful burning report is received from the burning client 30, automated testing should be initiated immediately for the device." Based on this rule, the edge service 20 immediately constructs a test trigger command. This command can also be a JSON object, for example: {"command":"start_test","device_id":"XX:XX:XX:XX:XX:XX","testcase_id":"factory_basic_qa"}. Subsequently, the edge service 20 publishes this command via the MQTT communication bus 60 to the topic being listened to by the test agent 40, such as factory / line1 / proxies / commands.

[0057] The third stage is automated testing and result reporting, which corresponds to... Figure 2 Steps S105 and S106 in the process. That is, the test agent parses the test case, pairs with the Matter device and executes the test, and reports the test results to the edge service.

[0058] As one implementation, the test agent 40 can be a single-board computer (such as a Raspberry Pi) equipped with Bluetooth and Thread wireless communication modules, which runs continuously in the background and listens to a specified MQTT topic. Upon receiving the aforementioned test trigger command, it begins executing the test task.

[0059] First, Test Agent 40 reads the corresponding test case file from its local cache based on the device_id and testcase_id in the instruction, parses the file, and loads the test steps, parameters, and assertion conditions into memory.

[0060] Next, test agent 40 begins interacting with the newly flashed Matter device 50. A typical test process is as follows: Test agent 40 first initiates a Bluetooth Low Energy scan to find a Matter device that is broadcasting and matches the device_id in the command. After finding the device, test agent 40 simulates a debug terminal in the Matter ecosystem, establishes a secure connection with Matter device 50 via Bluetooth, and initiates a pairing process. During pairing, test agent 40 provides Matter device 50 with credentials for a preset test network (e.g., a dedicated Thread test network). After receiving the credentials, Matter device 50 attempts to join the test network, and test agent 40 continuously monitors the device status until it confirms successful network access. After successful network access, test agent 40 begins performing functional tests. Depending on the use case definition, it may send standard Zigbee cluster library commands to the device via the Thread network; for example, if the device is a smart socket, it may send "on" and "off" commands and read the device's status attributes to verify whether they are consistent with expectations. After all test steps are completed, test agent 40 generates a detailed test result.

[0061] Finally, test agent 40 reports the test results. It packages the test results, including the final test conclusion (pass / fail), the execution status of each step, detailed communication logs, and time consumption, into a JSON object. This result is first reported to edge service 20, which can be done via the edge service 20's API (e.g., http: / / <edge-server-ip>This can be accomplished by sending an HTTP POST request to :8080 / report-test-status.

[0062] After receiving the test results, edge service 20 records them locally and integrates them with previously received programming results before reporting them to cloud service 10 via MQTT communication bus 60. Upon receiving the final complete report, the backend service of cloud service 10 updates the production status of the device in its central database, for example, from "programming complete" to "test passed." Correspondingly, production line administrators can view the complete lifecycle status of each device in real time on the dashboard interface of cloud service 10 and generate quality reports for the entire batch at any time.

[0063] In summary, through the above process, this embodiment realizes a fully automated process from cloud task creation to edge execution and result closed-loop feedback, tightly coupling programming and testing to achieve "programming is testing", thereby fundamentally eliminating the risk of missed detections and greatly improving production efficiency.

[0064] Example 2

[0065] This embodiment aims to illustrate the flexibility of the system and method provided in this application. Specifically, the testing process can be completely decoupled from the burning process on the production line and run independently. It is understood that this mode is particularly suitable for scenarios such as firmware regression testing during the R&D phase, quality spot checks on devices already shipped, or after-sales fault reproduction.

[0066] Please see Figure 4 This diagram illustrates the timing of the automated testing process for independent functions in this embodiment. In this scenario, the interaction primarily occurs between the user (e.g., a test engineer), the cloud service 10, the test agent 40, and the Matter device 50 under test, while the edge service 20 and the programming client 30 do not directly participate in this process.

[0067] The process is described as follows:

[0068] First, the test engineer logs into the web interface of cloud service 10 to create a separate test plan. Unlike Example 1, the engineer does not need to create a flashing batch; instead, they access a dedicated "Automated Testing" or "R&D Testing" module. Here, they can create a new "Test Plan," specifying a plan name (e.g., "V1.3 Firmware Network Stability Regression Test") during the creation process, and selecting one or more test agents 40 from the system's registered list of test agents to execute this plan (e.g., selecting "Lab-TestProxy-01" located in the R&D lab).

[0069] Next, the test engineer selects the necessary test cases for the test plan from the central test case library of Cloud Service 10. These test cases may be more complex and in-depth than the basic verification test cases in the production line, and may include, for example, "multi-administrator pairing test", "weak network signal scenario test", "long-term operation stability test" or "compatibility test with different ecosystems". After configuration, the engineer starts the test plan.

[0070] Subsequently, after receiving the start command, cloud service 10 will directly send the test plan and all associated test cases to the designated test agent 40 via MQTT communication bus 60. This communication can use point-to-point topics, such as proxies / Lab-TestProxy-01 / plans, to ensure that only the designated test agent can receive the task.

[0071] Then, the test agent 40 located in the laboratory receives the test plan, parses its contents, and may prompt the operator through a connected monitor or log output: "Please connect the device under test to perform 'V1.3 firmware network stability regression test'". The test engineer powers on a Matter device 50 that has already been flashed with V1.3 firmware and places it within the effective communication range of the test agent 40.

[0072] Upon detecting a device (or being manually triggered by an engineer), the test agent 40 automatically executes all test cases defined in the test plan. For example, when performing a "weak network signal scenario test," the test agent 40 can dynamically adjust the wireless signal strength by controlling a programmable signal attenuator, while simultaneously sending instructions to the Matter device 50 and checking its response success rate and latency to evaluate the device's performance in harsh network environments.

[0073] During test execution or after the entire test plan is completed, test agent 40 will submit a complete report containing the results of all test case executions to cloud service 10. For example... Figure 4 As shown, the reporting path is directly from test agent 40 to cloud service 10.

[0074] Finally, after receiving the test results, the cloud service 10 will associate them with the corresponding test plan and automatically update the execution status of the plan (such as "in progress", "completed", "failed"). At the same time, the system can automatically generate a graphic test report based on the reported detailed data, highlighting key information such as failed test cases and performance bottlenecks, providing test engineers with intuitive data support to quickly locate firmware defects.

[0075] Therefore, this embodiment demonstrates another important value of the proposed solution: it can serve not only as a production tool but also as a flexible, remotely scheduled, and manageable automated testing platform. By freeing testing capabilities from the production line, the utilization rate of testing resources (i.e., test agent 40) can be greatly improved, supporting diverse testing needs and thus accelerating the product development and iteration cycle.

[0076] Example 3

[0077] Based on Example 1, this embodiment further specifies the parallel processing capability and robust design of the system in detail to demonstrate how the solution of this application can cope with large-scale, high-throughput industrial production environments and ensure stable and reliable operation in complex electromagnetic and network environments.

[0078] First, to enhance the system's parallel processing capabilities, this embodiment optimizes the internal implementation of the burning client 30 and the test agent 40.

[0079] As a preferred implementation, the programming client 30 can be designed as a multi-threaded or multi-process application to support parallel programming. For example, a programming station may be equipped with a USB hub connecting eight programming devices. When the programming client 30 starts, it initializes a fixed-size thread pool (e.g., containing eight worker threads), scans and identifies all connected programming devices, and assigns a unique ID to each device. When the programming client 30 obtains batch information containing programming tasks for multiple devices from the edge service 20, it breaks these tasks down into independent subtasks and places them in a task queue. The worker threads in the thread pool concurrently retrieve tasks from the queue and execute them. Each thread is independently responsible for the complete programming process of a Matter device 50, including requesting certificates, downloading firmware, performing programming, verifying data, and reporting results. Accordingly, this design ensures that the programming failure of a single device (e.g., a hardware failure preventing writing) will not block or affect the programming process of other devices, thus allowing programming of multiple devices simultaneously and greatly improving output per unit time.

[0080] Similarly, test agent 40 can also support parallel testing. During peak production periods, multiple programming clients 30 may complete programming of a large number of devices in a short period of time, causing edge service 20 to send test trigger commands to test agent 40 intensively. To cope with this sudden traffic surge, test agent 40 can also adopt a producer-consumer pattern internally. Its main thread acts as a producer, responsible for listening to MQTT messages. When a test command is received, it is quickly placed into a first-in-first-out task queue. At the same time, a pool of worker threads acts as consumers, with multiple worker threads in the pool (e.g., the number can be configured according to the hardware performance of test agent 40 and the complexity of the wireless environment) concurrently retrieving tasks from the queue for processing. Each thread independently establishes a connection with a Matter device 50, executes complete test cases, and reports the results. This ensures that test agent 40 can efficiently handle concurrent test requests, avoids task backlog, and prevents the testing process from becoming a bottleneck in the production line.

[0081] Secondly, to enhance system robustness, this embodiment introduces an environment self-check and operation retry mechanism. As an optional implementation, when the application of test agent 40 starts or registers its services with the cloud / edge, a local environment self-check procedure is forcibly executed. This self-check procedure includes, but is not limited to: performing network connectivity checks, attempting to establish network connections with key endpoints of edge service 20 and cloud service 10 to ensure normal communication links; performing wireless adapter status checks, by executing system commands (e.g., hciconfig or iwconfig under Linux) to check whether the Bluetooth and Wi-Fi adapters are correctly recognized by the system and are in an active state, or by calling the corresponding control tools (such as ot-ctl) to check the status of the OpenThread protocol stack; and performing dependency service checks to confirm whether other services or tools required for local operation are normal. If any self-check fails, test agent 40 will report an abnormal status message containing specific error information to cloud service 10 and will prevent itself from entering the working state of receiving test tasks until the environmental problem is fixed. Understandably, this proactive self-checking mechanism can effectively prevent a large number of tests from being misjudged and failing due to problems with the test node's own environment (such as driver failure or network configuration errors).

[0082] Furthermore, to address common unreliable factors in industrial environments such as network fluctuations and transient interference, this embodiment incorporates retry logic in critical operations. For example, during the process of the programming client 30 requesting a device authentication certificate from the edge service 20, if the request fails due to network timeout, the client will not immediately mark the device as failed. Instead, it will initiate a retry loop employing an exponential backoff strategy. Specifically, it can wait 1 second before retrying for the first time. If it fails again, it will wait 2 seconds before retrying for the second time, and so on, until the preset maximum number of retries (e.g., 3 times) is reached. Only after all retries have failed is the operation finally determined to have failed and an error reported. Similarly, when the test agent 40 attempts to establish a Bluetooth connection with the Matter device 50, if the initial attempt fails, it can also be configured to retrace several times. It is easy to understand that this retry mechanism significantly enhances the fault tolerance of the entire process, reduces production interruptions and unnecessary defective product determinations caused by transient, non-fundamental problems, and improves the overall stability and reliability of the system.

[0083] Example 4

[0084] This embodiment focuses on a core and sensitive aspect of the Matter device manufacturing process—the issuance of device certification certificates—and provides a specific implementation scheme optimized through edge services 20. This scheme aims to reduce reliance on cloud networks, improve issuance efficiency, and enhance the security of the certificate system.

[0085] Under the Matter protocol, each device must hold a unique device certification certificate issued by a product certification intermediary as its trusted identity credential within the ecosystem. Traditionally, this might involve the device connecting to a cloud server for online certification during the flashing process, but this can introduce latency and single-point-of-dependency risks in high-density production environments. This embodiment addresses this issue by pushing certification capabilities down to the edge.

[0086] The specific working process of this solution is a detailed expansion of the burning operation in Example 1, and its flow is as follows:

[0087] First, the certificate chain and keys are pre-configured. During the production preparation phase, manufacturers need to securely deploy their product authentication intermediate certificate and its corresponding private key to the production site. In this embodiment, the core digital asset—the product authentication intermediate certificate private key—is pre-configured in a hardware security module connected to the industrial computer running edge service 20, or at least stored in a secure key storage area protected by the operating system. The product authentication intermediate certificate itself (the public key portion) can be distributed by cloud service 10 along with batch information or pre-configured in edge service 20. In this way, the high-security private key is strictly confined to the physically secure production intranet environment, avoiding the risk of direct transmission or exposure on the public internet.

[0088] Next, when the programming client 30 on the production line begins to perform a programming operation on a specific Matter device 50, it needs to obtain a unique device authentication certificate for that device. At this time, the programming client 30 will first generate a new public-private key pair (i.e., device authentication certificate key pair) for the device on the device or locally on the client, and then use the device's unique information (such as MAC address and serial number) and the newly generated public key to construct a standard certificate issuance request.

[0089] Unlike traditional online issuance, the burning client 30 does not send the certificate issuance request to the remote cloud service 10, but instead sends it to the edge service 20 deployed within the same local area network. This request can be an HTTP request pointing to a specific API endpoint of the edge service 20 (e.g., POST / api / v1 / sign-dac), with the certificate issuance request data contained in the request body.

[0090] After receiving a certificate issuance request from the programming client 30, the edge service 20 executes its local issuance logic. Specifically, it first verifies the legitimacy of the request (e.g., checks if the request source IP is within the permitted range), and then parses the certificate issuance request to extract the device's public key and related information. Subsequently, the edge service 20 calls its integrated hardware security module or security key storage interface to sign the received certificate issuance request using the pre-installed product authentication intermediate certificate private key. This signing process is completed instantly locally without involving any public network communication. The result of the signing operation is the generation of a complete device authentication certificate conforming to the Matter specification, which binds the device's public key, unique identifier, and the root of trust of the product authentication intermediate authority. Finally, the edge service 20 returns the newly generated device authentication certificate as a response to the requesting programming client 30.

[0091] After receiving the device authentication certificate returned by the edge service 20, the burning client 30 writes it together with the previously generated device authentication certificate private key, product authentication intermediate certificate, authentication statement and other information into the designated secure storage area (such as the OTP area or encrypted flash memory area) of the Matter device 50.

[0092] The benefits of this solution are obvious: First, it significantly reduces network latency because the issuance process only involves local area network communication, avoiding unpredictable public network latency and jitter with cloud servers, thereby significantly improving the burning speed of individual devices and overall production line efficiency. Second, it enhances security. The core asset of the intermediate certificate private key for product authentication is locked in a controlled environment within the production intranet, effectively reducing the risk of interception during transmission or attack in the cloud. Third, it improves production reliability. Even if the connection between the factory and the public network is temporarily interrupted, as long as the intranet is normal, certificate issuance and device burning can continue, ensuring production continuity. This embodiment provides strong technical support for achieving efficient, secure, and reliable large-scale production of Matter devices.

[0093] In summary, compared with the prior art, this application has the following beneficial effects:

[0094] 1. Seamless automated integration of programming and testing has been achieved. After receiving the programming result, the edge service automatically triggers the test agent, connecting the two originally independent links into a closed-loop automated process, realizing "programming is testing", and fundamentally eliminating the risk of human oversight or missed detection caused by process disconnection.

[0095] 2. It ensures the uniformity and reliability of testing standards. Test cases are centrally managed and uniformly distributed by cloud services, ensuring that all test agents in the production site use the same set of standards for testing, avoiding product quality fluctuations caused by inconsistent test case versions, and improving the traceability of test results.

[0096] 3. Enhanced system scalability and flexibility: Based on the distributed collaborative architecture of "cloud-edge-device", edge services and test nodes can be easily deployed on demand in different production lines and managed uniformly through the cloud. The system has good scalability and can meet the needs of large-scale production.

[0097] 4. Significantly improves production and testing efficiency. Automated processes replace cumbersome manual operations and support parallel programming and parallel testing, greatly increasing the throughput of the production line.

[0098] It is understood that the same or similar parts in the above embodiments can be referred to each other, and the contents not described in detail in some embodiments can be referred to the same or similar contents in other embodiments.

[0099] It should be noted that in the description of this invention, the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance. Furthermore, in the description of this invention, unless otherwise stated, "a plurality of" means at least two.

[0100] Any process or method description in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or process, and the scope of the preferred embodiments of the invention includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as will be understood by those skilled in the art to which embodiments of the invention pertain.

[0101] It should be understood that various parts of the present invention can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented in software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0102] Those skilled in the art will understand that all or part of the steps of the methods implementing the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0103] Furthermore, the functional units in the various embodiments of this invention can be integrated into a single processing module, or each unit can exist physically separately, or two or more units can be integrated into a single module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. The aforementioned storage medium can be a read-only memory, a disk, or an optical disk, etc.

[0104] In the description of this specification, references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0105] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention.

Claims

1. An automated testing method for Matter devices based on cloud-edge collaboration, characterized in that, Includes the following steps: Step 1: The cloud service creates a flashing batch containing firmware and certificate information and configures test cases associated with the flashing batch; the cloud service synchronizes the flashing batch to the edge service and the test cases to the test agent; Step 2: The programming client obtains the programming batch information from the edge service, performs the programming operation on the Matter device, and notifies the edge service of the programming result after the programming is completed; Step 3: After receiving the burning result, the edge service automatically triggers the test agent to start automated testing on the Matter device that has completed the burning process; Step 4: The test agent parses the test case, pairs with the Matter device and executes the test, and reports the test results to the edge service.

2. The method according to claim 1, characterized in that, Following step one, the method further includes: After receiving the test case, the test agent caches the test case locally for use when it is triggered.

3. The method according to claim 1, characterized in that, In step two, before the burning client performs the burning operation on the Matter device, the method further includes: The programming client sends a request to the edge service to issue a device authentication certificate for the Matter device.

4. The method according to claim 1, characterized in that, Includes at least one of the following: The programming client supports parallel programming of multiple Matter devices; The test agent supports parallel testing of multiple Matter devices.

5. The method according to claim 1, characterized in that, The method further includes at least one of the following: Before the test agent receives the test task, it performs a local environment self-check and reports an error if the self-check is abnormal. If the burning operation or test fails, a preset retry operation is performed.

6. The method according to claim 1, characterized in that, Following step four, the method further includes: The edge service collects and reports the test results to the cloud service; The cloud service updates the status of the burning batch and generates a test report based on the test results.

7. An automated testing system for Matter devices based on cloud-edge collaboration, characterized in that, include: The cloud service is used to create flashing batches containing firmware and certificate information, configure test cases associated with the flashing batches, synchronize the flashing batches to the edge service, and synchronize the test cases to the test agent. The programming client is used to obtain the programming batch information from the edge service, perform programming operations on the Matter device, and notify the edge service of the programming results after programming is completed. The test agent is used to receive and parse the test cases, pair with the Matter device and execute the test after being triggered, and report the test results to the edge service. An edge service is used to receive the burning batch from the cloud service, provide the burning batch information to the burning client, and automatically trigger the test agent to start automated testing on the Matter device that has completed burning after receiving the burning result reported by the burning client.

Images