Building automation bus device burning method, system, device, storage medium and program product

Abstract

Embodiments of the present application provide a burning method, system, device, storage medium and program product of a building automation bus device. The method comprises: a burning server acquiring firmware and database files to be burned; the burning server constructing a burning package according to the firmware and the database files; a burning host computer acquiring the burning package from the burning server, and performing version compatibility verification on the firmware and the database files in the burning package according to a preset compatibility matrix, and burning the firmware and the database files to the building automation bus device in the case that the version compatibility verification of the firmware and the database files is passed; and in the case that the burning is completed, the burning host computer performing database format verification and protocol stack testing on target firmware and target database files in the building automation bus device, and determining that the burning of the building automation bus device is successful in the case that the database format verification and the protocol stack testing are both passed, so that the versions of the firmware and the database files can be accurately matched.

Description

Technical Field

[0001] This application relates to the field of intelligent building control, and in particular to a method, system, device, storage medium and program product for programming building automation bus devices. Background Technology

[0002] Intelligent building control systems rely on various building automation bus devices to perform management functions such as the linkage of electromechanical equipment within the building, real-time environmental monitoring, and scene control. Before leaving the factory, each building automation bus device must undergo a production line programming process to pre-set basic data. During this programming stage, two types of data need to be written to the storage unit of the building automation bus device: the firmware required for the device to run and the database file used for device configuration and addressing.

[0003] Currently, the firmware and database file burning process is usually executed in a serial manner. In one implementation, the firmware is first burned to the main control chip of the building automation bus device, then the building automation bus device is assembled, and then, with the building automation bus device powered on and in operation, the database file is written to the building automation bus device using the protocol stack in the firmware. During the firmware and database file burning preparation stage, operators usually check the version compatibility of the firmware and database file to be burned by checking the version matching relationship recorded in the production line task sheet or work order system posted on the Kanban board. Only after confirmation can the burning be performed.

[0004] However, when multiple firmware versions and database file versions exist on the production line at the same time, this implementation method is prone to version confusion due to the complex version matching relationship and multiple manual verification steps. This can lead to version mismatch between the firmware and the database file, causing abnormalities in the subsequent full-function testing phase of the building automation bus equipment, thereby significantly reducing the programming pass rate and increasing the repair rate of the building automation bus equipment. Summary of the Invention

[0005] This application provides a method, system, device, storage medium, and program product for burning firmware to a building automation bus device, which can achieve accurate version matching between firmware and database files, thereby effectively improving the reliability of burning and reducing the repair rate of building automation bus devices.

[0006] In a first aspect, embodiments of this application provide a method for programming building automation bus devices, applied to a building automation bus device programming system. The building automation bus device programming system includes a programming server and a programming host computer. The method includes:

[0007] The burning server acquires the firmware and database file to be burned; the firmware is an executable program image for the operation of the building automation bus device, and the database file is a parameter description file for the communication and function configuration of the building automation bus device.

[0008] The burning server constructs a burning package based on the firmware and the database file;

[0009] The programming host computer obtains the programming package from the programming server and performs version compatibility verification on the firmware and the database file in the programming package according to the preset compatibility matrix. If the version compatibility verification of the firmware and the database file passes, the firmware and the database file are programmed into the building automation bus device.

[0010] Once the burning process is complete, the burning host computer performs database format verification and protocol stack testing on the target firmware and target database file in the building automation bus device. If both the database format verification and protocol stack testing pass, the burning of the building automation bus device is confirmed to be successful.

[0011] In some implementations, the programming host computer performs database format verification on the target firmware and target database file in the building automation bus device, including:

[0012] The host computer reads the minimum database format version supported by the protocol stack in the target firmware, as well as the format version of the target database file;

[0013] If the format version of the target database file is higher than or equal to the minimum database format version, then the database format verification is deemed successful.

[0014] If the format version of the target database file is lower than the minimum database format version, then the database format verification is determined to fail.

[0015] In some embodiments, the programming host computer performs protocol stack testing on the target firmware and target database file in the building automation bus device, and the method further includes:

[0016] The programming host computer sends a start command to the building automation bus device to start the protocol stack of the building automation bus device;

[0017] Send a broadcast message to the bus of the building automation bus device;

[0018] If a confirmation response from the protocol stack is received within the preset time, the protocol stack test is considered successful.

[0019] If no confirmation response is received within the preset time, or if a negative response from the protocol stack is received within the preset time, the protocol stack test is determined to have failed.

[0020] In some implementations, the burning server constructs a burning package based on the firmware and the database file, including:

[0021] The burning server determines a first verification benchmark value for the firmware and a second verification benchmark value for the database file;

[0022] The flashing package is constructed based on the first verification benchmark value, the second verification benchmark value, the firmware, and the database file.

[0023] In some implementations, the programming host computer performs database format verification and protocol stack testing on the target firmware and target database file in the building automation bus device, including:

[0024] The host computer determines a first verification target value for the target firmware and a second verification target value for the target database file. If the first verification target value matches the first verification benchmark value, and the second verification target value matches the second verification benchmark value, the host computer performs database format verification and protocol stack testing on the target firmware and target database file in the building automation bus device. If the first verification target value does not match the first verification benchmark value, and / or the second verification target value does not match the second verification benchmark value, the step of burning the firmware and the database file to the building automation bus device is re-executed, and this step is repeated until the first verification target value matches the first verification benchmark value, and the second verification target value matches the second verification benchmark value, or until the maximum number of repetitions is reached. If so, a burning error is determined, and rework information for the building automation bus device is generated.

[0025] In some embodiments, the method further includes:

[0026] If the firmware and the database file version compatibility check fails, the burning host computer sends a first indication message to the burning server. The first indication message is used to indicate that the firmware and the database file version compatibility check failed.

[0027] The burning server updates the firmware or the database file based on the first instruction information and reconstructs the burning package.

[0028] In some embodiments, the method further includes:

[0029] The programming host computer obtains the compatibility matrix from the manufacturing execution system through a preset interface.

[0030] In some embodiments, the method further includes:

[0031] If the database format verification between the target firmware and the target database file fails, the burning host computer sends a second indication message to the burning server. The second indication message is used to indicate that the database format verification failed.

[0032] The burning server updates the format version of the database file or updates the protocol stack of the firmware according to the second instruction information to update the minimum database format version supported by the protocol stack of the firmware, and reconstructs the burning package.

[0033] Secondly, embodiments of this application provide a building automation bus device programming system, the building automation bus device programming system comprising: a programming server and a programming host computer;

[0034] The burning server acquires the firmware and database file to be burned; the firmware is an executable program image for the operation of the building automation bus device, and the database file is a parameter description file for the communication and function configuration of the building automation bus device.

[0035] The burning server constructs a burning package based on the firmware and the database file;

[0036] The programming host computer obtains the programming package from the programming server and performs version compatibility verification on the firmware and the database file in the programming package according to the preset compatibility matrix. If the version compatibility verification of the firmware and the database file passes, the firmware and the database file are programmed into the building automation bus device.

[0037] Once the burning process is complete, the burning host computer performs database format verification and protocol stack testing on the target firmware and target database file in the building automation bus device. If both the database format verification and protocol stack testing pass, the burning of the building automation bus device is confirmed to be successful.

[0038] In some embodiments, the programming host computer is used for:

[0039] Read the minimum database format version supported by the protocol stack in the target firmware, and the format version of the target database file;

[0040] If the format version of the target database file is higher than or equal to the minimum database format version, then the database format verification is deemed successful.

[0041] If the format version of the target database file is lower than the minimum database format version, then the database format verification is determined to fail.

[0042] In some embodiments, the programming host computer is used for:

[0043] Send a start command to the building automation bus device to start the protocol stack of the building automation bus device;

[0044] Send a broadcast message to the bus of the building automation bus device;

[0045] If a confirmation response from the protocol stack is received within the preset time, the protocol stack test is considered successful.

[0046] If no confirmation response is received within the preset time, or if a negative response from the protocol stack is received within the preset time, the protocol stack test is determined to have failed.

[0047] In some embodiments, the programming server is used for:

[0048] Determine the first verification benchmark value of the firmware and the second verification benchmark value of the database file;

[0049] The flashing package is constructed based on the first verification benchmark value, the second verification benchmark value, the firmware, and the database file.

[0050] In some embodiments, the programming host computer is used for:

[0051] A first verification target value for the target firmware and a second verification target value for the target database file are determined. If the first verification target value matches the first verification benchmark value, and the second verification target value matches the second verification benchmark value, database format verification and protocol stack testing are performed on the target firmware and target database file in the building automation bus device. If the first verification target value does not match the first verification benchmark value, and / or the second verification target value does not match the second verification benchmark value, the step of burning the firmware and the database file to the building automation bus device is re-executed, and this step is repeated until the first verification target value matches the first verification benchmark value, and the second verification target value matches the second verification benchmark value, or until the maximum number of repetitions is reached. If so, a burning error is determined, and rework processing information for the building automation bus device is generated.

[0052] In some embodiments, the programming host computer is used for:

[0053] If the version compatibility check between the firmware and the database file fails, a first indication message is sent to the burning server. The first indication message is used to indicate that the version compatibility check between the firmware and the database file has failed.

[0054] The burning server updates the firmware or the database file based on the first instruction information and reconstructs the burning package.

[0055] In some embodiments, the programming host computer is used for:

[0056] The compatibility matrix is ​​obtained from the manufacturing execution system through a preset interface.

[0057] In some embodiments, the programming host computer is used for:

[0058] If the database format verification between the target firmware and the target database file fails, a second indication message is sent to the burning server. The second indication message is used to indicate that the database format verification failed.

[0059] The burning server updates the format version of the database file or updates the protocol stack of the firmware according to the second instruction information to update the minimum database format version supported by the protocol stack of the firmware, and reconstructs the burning package.

[0060] Thirdly, embodiments of this application provide an electronic device, the electronic device comprising:

[0061] At least one processor; and a memory communicatively connected to said at least one processor;

[0062] The memory stores instructions that can be executed by the at least one processor to cause the electronic device to perform the method described in the first aspect.

[0063] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the method described in the first aspect.

[0064] Fifthly, embodiments of this application provide a computer program product, the computer program product including a computer program, which, when executed by a processor, implements the method described in the first aspect.

[0065] This application provides a method, system, device, storage medium, and program product for programming building automation bus devices. The programming server first obtains the firmware and database files to be programmed. Then, the programming server constructs a programming package based on the firmware and database files. A programming host computer obtains the programming package from the programming server and performs version compatibility verification on the firmware and database files in the programming package according to a preset compatibility matrix. If the version compatibility verification of the firmware and database files passes, the firmware and database files are programmed into the building automation bus device. After programming is complete, the programming host computer performs database format verification and protocol stack testing on the target firmware and target database files in the building automation bus device. If both database format verification and protocol stack testing pass, the programming of the building automation bus device is considered successful. This method ensures that the firmware and database files match in terms of version by introducing version compatibility verification based on a compatibility matrix before programming, and further performs database format verification and protocol stack function testing after programming, verifying the correctness of the programmed content from two dimensions: protocol stack parsing compatibility and actual communication function. This achieves accurate matching between firmware and database files, effectively reducing operational failures of building automation bus equipment caused by version mismatch, format incompatibility, or protocol stack anomalies. In particular, it can significantly reduce the risk of version mismatch in mixed production lines, improve the successful burning rate, and detect and intercept version and protocol-related issues that could only be detected during the overall functional testing stage at the burning stage. This effectively reduces the return rate and maintenance costs of building automation bus equipment, shortens the problem location time, and improves production efficiency. Attached Figure Description

[0066] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0067] Figure 1 This application provides an illustration of the correspondence between firmware and database file versions supported by a building automation bus device, as shown in the embodiments of this application. Figure 1 ;

[0068] Figure 2 This application provides an illustration of the correspondence between firmware and database file versions supported by a building automation bus device, as shown in the embodiments of this application. Figure 2 ;

[0069] Figure 3 A flowchart illustrating a method for programming a building automation bus device, as provided in an embodiment of this application;

[0070] Figure 4 A flowchart illustrating a method for constructing a programming package as provided in an embodiment of this application;

[0071] Figure 5 This is a schematic diagram illustrating the consistency between the verification target value and the verification benchmark value, provided in an embodiment of this application.

[0072] Figure 6 This is a schematic diagram illustrating an inconsistency between a target value and a benchmark value for verification, provided as an embodiment of this application.

[0073] Figure 7 A flowchart illustrating a database format verification method provided in this application embodiment;

[0074] Figure 8 A flowchart illustrating a method for handling database format validation failures provided in this application embodiment;

[0075] Figure 9 A flowchart illustrating a protocol stack testing method provided in an embodiment of this application;

[0076] Figure 10 A schematic diagram of a building automation bus device programming system provided in this application embodiment;

[0077] Figure 11 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0078] It should be noted that 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 application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with relevant laws, regulations and standards, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0079] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0080] The terminology used in the embodiments of this application will be introduced.

[0081] Firmware refers to a set of program instructions and data embedded in a hardware device, which is the low-level control code between the hardware and the upper-level software. In the embodiments of this application, the firmware mainly includes bootloader, system partition image, manufacturer hardware adaptation partition image, and user data partition image, etc., which are used to realize the hardware initialization, operating system loading, and basic function operation of the building automation bus device.

[0082] Database: In this embodiment of the application, the database refers to a collection of configuration data required for the operation of building automation bus devices, which mainly includes configuration parameters, device attribute information, communication protocol parameters, group address table, personal address and communication object association table, etc.

[0083] The bootloader is the first firmware program executed after an embedded system is powered on or reset. It sits between the hardware and the operating system kernel and is mainly responsible for initializing critical hardware, configuring the basic system operating environment, ensuring that subsequent software can execute normally, and finally loading the operating system kernel into memory and transferring control to the operating system kernel.

[0084] System partition: A container for storing system framework and system-level application library files, mainly including the framework layer, system services, pre-installed system applications, and various native libraries and core components required for system operation.

[0085] The vendor hardware adaptation section mainly includes the Hardware Abstraction Layer (HAL) implementation, device drivers, firmware images, and configuration files and calibration parameters specific to the hardware platform. The HAL is a software interface layer that exists between the operating system kernel and the hardware circuitry.

[0086] User data partition: Used to store user-generated or installed data, such as third-party applications, photos, audio, video, and personalized settings preferences. In this embodiment, since user data has not been written during the production line flashing stage, and the User data partition has read and write permissions after system startup, it is suitable as a storage location for dynamically loaded configuration files at runtime. Based on this, placing the database file in User data allows for flexible reading and writing during system operation and prevents it from being overwritten by the system partition during subsequent firmware online upgrades, thereby effectively ensuring the persistence and integrity of the configuration data.

[0087] Group Address Table: In this embodiment, the group address table is a list of logical channels used for multicast communication on the building automation bus device. It stores one or more group addresses in a "master / middle / slave" format (e.g., 1 / 2 / 3). The "master" field represents a functional domain or building area (e.g., lighting, HVAC, or floor number), the "middle" field represents a sub-functional category or spatial subdivision under that domain (e.g., dimming control or a specific room), and the "slave" field represents a specific functional point or actuator number under that category (e.g., a switch command or a specific circuit). In other words, each group address collectively represents a functional group (e.g., a "living room lighting group"), used to logically group multiple devices scattered in different physical locations into the same control set. When a device on the bus sends a control command to this group address, all devices configured with that group address in their own communication object association table will synchronously receive and execute the response, thereby achieving one-to-many linkage control based on groups.

[0088] Personal address: In this embodiment of the application, the personal address is a unique physical identifier assigned to each building automation bus device, which is equivalent to the "ID number" of the building automation bus device on the bus, and is used for point-to-point addressing and communication in the network.

[0089] Communication Object Association Table: In this embodiment, the communication object association table defines the configuration rules for the mapping relationship between various functional endpoints (such as switches, dimming devices, status feedback devices, etc.) within the building automation bus device and external group addresses. This table determines which group address commands each specific functional point of the building automation bus device should monitor or respond to. For example, a dimming device binds its "dimming value" object to the "1 / 2 / 4" group address through this communication object association table, thus clarifying that this function is only controlled by commands from that group address.

[0090] Embedded Multi Media Card (eMMC): is a standard for flash memory cards that defines the physical architecture, access interface, and protocol of storage systems based on embedded multimedia cards. It is a non-volatile memory, meaning that data is not lost after power is off.

[0091] Universal Flash Storage (UFS) is a serial interface flash storage standard designed for mobile devices and computing systems. Its architecture mainly consists of a controller and NAND flash memory chips, and it uses a full-duplex serial channel to support simultaneous read and write operations.

[0092] A coprocessor is a chip or hardware module used to assist the central processing unit (CPU) in performing tasks that require high efficiency, such as floating-point operations, graphics rendering, signal processing, or encryption and decryption.

[0093] Electrically Erasable Programmable Read-Only Memory (EEPROM) is a non-volatile memory chip that does not lose data after power is turned off.

[0094] KNX (Konnex) is a universal, open standard protocol for smart home and building automation control. Simply put, KNX is like the nervous system of a building, integrating all subsystems such as lighting, air conditioning, shading, security, and energy management onto a unified platform for centralized control, monitoring, and management.

[0095] Manufacturing Execution System (MES) is a production management platform located between the enterprise's upper-level planning and management system and the lower-level industrial control system. It is responsible for managing information such as production plans, material batches, equipment configurations, personnel instructions, and process parameters.

[0096] HTTP RESTful API: A software communication interface based on the Hypertext Transfer Protocol (HTTP), following the Representational State Transfer (REST) ​​architectural style, abstracting data or functions on the server into a series of resources, and manipulating these resources through standard HTTP methods, such as GET, POST, PUT / Patch, and Delete.

[0097] Remote Procedure Call (RPC) is a communication protocol that allows a program to invoke a program or method on a server as if it were a local function.

[0098] Cyclic Redundancy Check 32 (CRC32) is a technique used to detect errors during data transmission. By appending check bits to the data, the receiver verifies the received data using the same calculation method to determine if the data has been altered or erroneous during transmission.

[0099] Secure Hash Algorithm (SHA): Generates a fixed-length "digital fingerprint," or hash value, for any data such as files, passwords, or messages. It is mainly used to verify data integrity, such as comparing the hash value after downloading a file to confirm whether it has been tampered with.

[0100] Message Digest Algorithm 5 (MD5): Compresses data of arbitrary length into a fixed-length "digital fingerprint" for file integrity verification (such as verifying whether a downloaded installation package is corrupted) and password storage.

[0101] Currently, the firmware and database file burning process is usually performed in a serial manner. In one implementation, the partition images of the firmware, including the Bootloader, System, Vendor, and Userdata, are first burned to the built-in memory of the main control chip of the building automation bus device, such as eMMC or UFS, via a Universal Serial Bus (USB) or Ethernet interface.

[0102] After firmware flashing is complete, the building automation bus device enters the final assembly stage, including casing packaging, interface assembly, and electrical connections. Once assembled, the building automation bus device must be powered on and its operating system must be started. Only when the operating system and protocol stack are functioning correctly can the data configuration tool establish a communication connection with the building automation bus device, thereby writing the database file to the target storage area.

[0103] The firmware is imaged for each partition because the image is a complete block-level copy of the original data of each partition. This accurately restores the file system structure, permission attributes, and boot parameters, ensuring that the flashed system has a consistent and predictable operating environment and avoiding fragmentation or permission mismatch issues caused by file-level copying. Furthermore, each partition is independent, facilitating modular deployment and individual upgrades. Specific partitions can be repaired or updated without rewriting the entire firmware. It also supports flexible combinations of different partition versions based on hardware configuration, adapting to the differences in various peripherals under the same main control chip.

[0104] In this operating state, relying on the protocol stack that has been started in the firmware, the operator uses a digital configuration tool to write the building automation bus device configuration data contained in the project file into the internal EEPROM of the coprocessor of the building automation bus device or the userdata partition in the firmware via the IP interface or USB to KNX interface.

[0105] The KNX interface is a standard interface used for device interconnection and communication in building automation systems. Project files are project configuration files created and exported using data configuration tools. They store configuration parameters, device attribute information, communication protocol parameters, group address tables, individual addresses, and communication object association tables, serving as the data basis for the operating logic and communication behavior of building automation bus devices.

[0106] During the firmware and database file burning preparation stage, operators usually check the version compatibility of the firmware and database file to be burned by checking the version matching relationship recorded in the production line task sheet or work order system posted on the Kanban board. Only after confirmation can the burning be performed.

[0107] However, in actual production scenarios, the same production line may simultaneously produce multiple models of building automation bus devices, resulting in multiple firmware versions and database file versions. Figure 1 The example shows the firmware and database file version correspondence supported by the building automation bus device, and... Figure 2 Taking the example of the correspondence between firmware and database file versions supported by a building automation bus device, each model of building automation bus device can support multiple firmware versions, and each firmware version can correspond to one or more compatible database file versions. For example... Figure 1 As shown, the A-type building automation bus device supports firmware versions including V2.0, V2.1, and V2.2. Firmware version V2.0 corresponds to one compatible database file version V3; firmware version V2.1 corresponds to three compatible database file versions, V3, V4, and V5; and firmware version V2.2 corresponds to four compatible database file versions, V5, V6, V7, and V8. Figure 2 As shown, the B-type building automation bus device supports firmware versions V4.1 and V4.2. Firmware version V4.1 corresponds to three compatible database file versions, namely V5, V6, and V7; firmware version V4.2 corresponds to two compatible database file versions, namely V6 and V7.

[0108] Furthermore, different firmware versions may rely on different protocol stack functions and configuration parameter structures. Therefore, there are specific and different requirements for the format version of the database file, that is, the layout specifications of the internal data structure of the database file, such as field definitions, indexing methods, and verification rules. For example, the protocol stack corresponding to firmware version V2.0 requires a minimum database file format version of v3.3; while in firmware version V2.1, the minimum format version requirements for different database file versions are also different: database file version V3 requires a minimum format version of v3.0, database file version V4 requires a minimum format version of v4.1, and database file version V5 requires a minimum format version of v5.2.

[0109] It should be noted that the version numbers and device models mentioned above are only illustrative examples. In actual production scenarios, there are far more firmware versions, database file versions, and building automation bus device models involved than in the examples, and the management situation is more complex. However, the version dependency logic is similar to the pattern shown in the examples.

[0110] In practice, the aforementioned firmware versions and database files are typically stored simultaneously on the production line server or in the tool directory. During manual verification, operators need to confirm the device model, current firmware version, list of available database file versions, minimum format requirements for each database file version, and whether the actual database file format on the server meets these requirements. This process involves cross-referencing multi-dimensional information, and the dependency rules differ between different models and firmware versions. The complexity of version matching relationships and the numerous manual verification steps can easily lead to version confusion, resulting in mismatches between firmware and database file versions.

[0111] If the firmware version is inconsistent with the database file version, it may cause the protocol stack initialization in the firmware to fail. However, under the above implementation method, this anomaly can only be discovered during the full-function testing phase of the building automation bus device. At this time, the building automation bus device is already in a complete state, requiring disassembly, re-flashing of the firmware and database file, reassembly, and another full-function test. This iterative process not only directly reduces the flashing pass rate but also significantly increases the rework rate, rework time, and material loss costs. It also consumes a large amount of testing resources and prolongs the average processing time per device. Furthermore, full-function testing itself is time-consuming; if a version mismatch occurs, the overall testing cycle will be further extended, causing the production line's production rhythm to fail to meet the cycle time requirements and reducing overall production efficiency.

[0112] To address the aforementioned issues, this application provides a method for programming building automation bus devices. This method introduces version compatibility verification based on a compatibility matrix before programming, and further performs database format verification and protocol stack function testing after programming. This ensures accurate matching between the firmware and the database file, effectively reducing operational failures of building automation bus devices caused by version mismatches, format incompatibility, or protocol stack anomalies. It significantly reduces the risk of version mismatches, improves the programming pass rate, and proactively detects and intercepts version and protocol-related issues that would otherwise only be detected during the overall device functional testing phase. This avoids wasted time and component wear from subsequent testing, disassembly, and rework, thereby effectively reducing the rework rate and maintenance costs of building automation bus devices.

[0113] Furthermore, because the problem discovery point is moved forward to the programming stage, fault isolation is clearer, the location time is greatly shortened, and the programming and verification process of a single building automation bus device is more efficient and controllable. This reduces repetitive work in the whole machine testing stage, significantly improves overall production efficiency and production line turnover speed, and can better meet the production line cycle requirements.

[0114] The technical solutions shown in this application will now be described in detail through specific embodiments. It should be noted that the following embodiments may exist independently or in combination with each other; for identical or similar content, the description will not be repeated in different embodiments.

[0115] Figure 3 This is a flowchart illustrating a method for programming building automation bus devices according to an embodiment of this application. The method is applied to a building automation bus device programming system, which includes a programming server and a programming host computer.

[0116] The building automation bus device programming system serves as the execution environment for the methods described in the embodiments of this application.

[0117] The programming server is a computing device with file management, task distribution, and data encapsulation capabilities. It can be deployed in the production line's local area network and establish data connections with the production management system, file repository, or local storage media to obtain the firmware files to be programmed, version information, and device configuration data. In this embodiment, the programming server is responsible for preparing programming-related files, generating programming packages, and uniformly managing and storing programming tasks.

[0118] The programming host computer is a terminal control device adapted to the building automation bus communication protocol, capable of device interaction and firmware programming. It can connect to the production line LAN and establish real-time communication with the programming server, receiving programming packages and programming task instructions from the programming server. In this embodiment, the programming host computer is responsible for communicating with the building automation bus device to be programmed, performing version verification, actual writing of programming data, result verification after programming, database format verification, and protocol stack testing, and generating programming logs and verification results.

[0119] like Figure 3 As shown, the method includes:

[0120] S301, The burning server obtains the firmware and database files to be burned.

[0121] Firmware is an executable program image used for the operation of building automation bus devices, while database files are parameter description files used for communication and function configuration of building automation bus devices. Database files can be derived from XML configuration files generated after unpacking KNX project files (such as knxproj), or from binary .db files generated through compilation.

[0122] After receiving a production line task, the programming server can obtain key production information of the building automation bus equipment corresponding to that task from the manufacturing execution system, including equipment model, serial number, batch number, and work order number. Based on this information, it determines the set of files required for this programming task and then retrieves the firmware and database files associated with that production line task from a pre-established file storage directory, version management repository, or external production management system.

[0123] Specifically, the programming server can access the file server via a network interface, using file path, version number, building automation bus device serial number, or production line task number as search criteria to read firmware and database files; it can also obtain the corresponding files by connecting to a local disk array, removable storage media, or a dedicated repository. To ensure the traceability of subsequent processing, the programming server can record key information after obtaining the firmware and database files, including but not limited to filename, file length, generation time, version number, building automation bus device serial number, and source of acquisition. This information can be written to the local operation log or simultaneously uploaded to the centralized traceability system for subsequent quality review.

[0124] S302, The burning server builds a burning package based on the firmware and database files.

[0125] When building the flashing package, the flashing server can uniformly encapsulate the firmware and database files corresponding to the current production line task. Through this encapsulation, the flashing host computer can obtain the firmware, database files, and their corresponding version information through a unified parsing interface in subsequent processes, thereby simplifying the file management process. Production line operators only need to maintain and transmit a single flashing package file, eliminating the need to manage multiple scattered files separately. This effectively avoids production anomalies caused by firmware and database mismatches or incorrect version selection, improving the reliability and traceability of the flashing operation.

[0126] In one implementation, the header of the flash package can be constructed first based on the firmware and database file. For example, the header may include the following fields: Magic (4B) = "CFLASH", Version (2B) = flash package version, Android_fw_version (32B) = firmware version; Knx_db_version (16B) = database file version.

[0127] The field "magic(4B) = "CFLASH"" occupies 4 bytes of storage space and stores the identifier string "CFLASH", which identifies the file format of the flash package as .cflash. When the flashing tool parses the flash package, it can first read this field and verify whether it is equal to "CFLASH". After the verification is successful, the flashing tool will then parse the subsequent fields according to the header definition, thereby ensuring that the subsequent parsing operations are based on a valid file format.

[0128] The field "Version (2B) = Flash Package Version" occupies 2 bytes of storage space and is used to identify the version number of the .cflash file format itself. With iterative upgrades to the flash package (e.g., V1→V2→V3), different versions of the flash package may have different header structures or field definitions. The flashing tool can correctly parse the header structure based on this version number. Furthermore, this field also supports version compatibility management. When an older version of the flashing tool encounters a newer version of the flash package, it can identify format incompatibility issues through version differences and proactively refuse parsing operations, avoiding parsing errors due to format mismatch, which could lead to subsequent version verification failures and other anomalies.

[0129] The field "Android_fw_version (32B) = firmware version" occupies 32 bytes of storage space and is used to store the firmware version information in the current flash package. The version format can adopt the "major version.minor version.revision_compilation date" specification, such as "V2.1.0_20260516", to clearly identify the firmware iteration status and build time.

[0130] The field “Knx_db_version (16B) = database file version” occupies 16 bytes of storage space and is used to store the version number of the database file encapsulated in the current flash package. The version format can refer to the firmware version specification and adopt a format similar to “major version.minor version.revision_compilation date” (such as “V1.0.2_20260516”).

[0131] The firmware version field uses 32 bytes because firmware is usually large in size and iterates frequently. The version number may contain additional information such as longer compilation dates, development branch identifiers, and release types, such as long-format version strings like "V2.1.0_20260516_release". The database file version uses 16 bytes because database versions usually have simple naming rules and stable change cycles. No additional extended identifiers are needed, and short storage space can fully accommodate the version information.

[0132] To further enhance the usability of the flash package, for example, the following fields can be added to the header of the flash package: knx_db_size (4B) = number of bytes in the database file and the field: reserved (64B) = reserved field.

[0133] The field "knx_db_size (4B) = number of bytes in the database file" occupies 4 bytes of storage space and is used to record the original size of the packaged database file. When the host computer parses the programming package, it can use this field to determine the length of the database file, thus providing a basis for subsequent database file parsing and writing operations, ensuring the integrity of the database file before writing and the accuracy of the writing process.

[0134] The field "reserved(64B) = reserved field" occupies 64 bytes of storage space and is used for future functional expansion of the flashing package format. This field can accommodate additional information that may be added in subsequent flashing package versions, such as verification, encryption identifiers, flashing address offsets, device type filtering conditions, etc. While maintaining the stability of the current header structure, it provides backward compatibility for functional requirements that may be added in subsequent flashing package versions, avoiding frequent adjustments to the overall layout due to new requirements.

[0135] After the header is built, the programming server concatenates and packages the header, firmware, and database files in sequence to generate a .cflash format programming package file. This ensures the uniformity and parsability of the programming package structure, enabling the subsequent programming of the host computer to accurately extract each part of the content based on a fixed position, avoiding parsing failures or programming errors due to disordered order.

[0136] The firmware portion can be organized according to a specific order of partition images, such as: Bootloader→System→Vendor→Userdata. This order is usually consistent with the chip boot process and the partition layout of the storage medium, ensuring that each partition of the firmware is written in sequence according to its dependency relationship during flashing, avoiding boot anomalies or verification failures caused by incomplete partition data.

[0137] To ensure the integrity and tamper-proof capability of the flash package during transmission and storage, the flashing server can also calculate a hash value for the entire .cflash file and append this hash value to the end of the file. When the host computer loads the flash package subsequently, it can recalculate the file hash and compare it with the hash value stored at the end to verify that the flash package is complete and has not been tampered with.

[0138] It should be noted that the .cflash file is merely an exemplary burning package and its format implementation provided in this application embodiment. In practical applications, other formats of burning package files can be generated according to specific usage scenarios and burning requirements, and the field definitions in the burning package header can be adjusted accordingly. For example, when defining the burning package format, the Magic field (4 bytes) in the header can be replaced with an identifier string corresponding to the current format to ensure that the burning tool can correctly identify and parse the burning package. In addition, other fields in the header, such as version number, package length, and verification information, can also be expanded or trimmed according to actual needs. This application embodiment does not impose any limitations on the specific format of the burning package or the content of its header fields, as long as the function of organizing and parsing burning data can be achieved.

[0139] S303: The host computer obtains the burning package from the burning server and performs version compatibility verification on the firmware and database files in the burning package according to the preset compatibility matrix. If the version compatibility verification of the firmware and database files passes, the firmware and database files are burned to the building automation bus device.

[0140] The compatibility matrix defines the correspondence between legally usable firmware versions and database file versions. For example, firmware version v2.1 is only allowed to match database version v3.0 and above, while firmware version v2.0 only supports database version v2.x series. It can be stored in the form of a mapping table or a rule base.

[0141] In one implementation, the programming host computer can obtain the compatibility matrix from the manufacturing execution system through a preset interface. The preset interface refers to a predefined communication channel between the programming host computer and the manufacturing execution system, such as an HTTP RESTful API or RPC call, used to actively request and obtain the latest compatibility matrix data according to a pre-defined format.

[0142] Furthermore, when R&D personnel or product management teams release new firmware or database files, the production line does not need to modify the host computer software. It only needs to dynamically obtain the latest compatibility matrix through a preset interface to adapt to the new version matching rules, thereby effectively reducing maintenance costs and the risk of human error, and significantly improving the production line's response efficiency to version changes.

[0143] Specifically, after the host computer receives the task instruction, it can send a request to the burning server to download the burning package. The download method can be file sharing, HTTP interface, transmission protocol, or message queue subscription.

[0144] After receiving the flashing package, the host computer first parses the package, reading the firmware version and database file version information. It then uses these two versions as lookup keys in the compatibility matrix, mapping the current firmware version to the corresponding rule range according to the version range set in the compatibility matrix, and determining whether the database version is within the allowed range. If the result is a successful pairing, the version compatibility check of the firmware and database file in the flashing package is considered passed; if the result is a failed pairing, the version compatibility check is considered failed, the host computer stops subsequent writing operations, and outputs exception information in the interface, logs, or alarm interface.

[0145] If the firmware and database file version compatibility verification passes, the programming host computer can establish a download connection with the building automation bus device and write the firmware and database files to the building automation bus device. The specific writing process can be executed according to the programming process supported by the building automation bus device so that the firmware and database files are written to the corresponding storage area. If an abnormality occurs during the writing process, the programming host computer can stop the current programming task and record the abnormal information.

[0146] In one implementation, the host computer can be connected to the debugging interface of the building automation bus device via a USB data cable, and the firmware partition images can be burned to the eMMC storage built into the building automation bus device in partition order based on the corresponding communication protocol.

[0147] After the firmware is burned, the database file can be pushed to a specified directory of the userdata partition image in the building automation bus device via a file transfer command, such as / data / knx / db / knx_config.db, thereby completing the burning of the database file.

[0148] Storing the database files in a separate directory on the userdata partition isolates them from application and system files, facilitating independent upgrades, backups, recovery, or maintenance of the database. It also reduces the risk of database file corruption due to application anomalies, improving system maintainability and data security.

[0149] If the firmware and database file version compatibility check fails, the host computer sends a first indication message to the programming server. The programming server updates the firmware or database file based on the first indication message and reconstructs the programming package. The first indication message indicates that the firmware and database file version compatibility check failed.

[0150] After updating the firmware or database file, the flashing server can reassemble a new flashing package based on the updated firmware or database file. Then, the flashing package is sent to the flashing host computer for a new compatibility check of subsequent versions.

[0151] Through the above processing, the host computer can promptly feed back the verification failure result to the burning server. Based on this, the server completes file updates and burning package reconstruction, so that the file to be burned meets the compatibility matrix requirements again, and provides a burning package that can be executed again for subsequent burning and verification, thereby realizing closed-loop correction in version mismatch scenarios.

[0152] S304. After the burning process is complete, the burning host computer performs database format verification and protocol stack testing on the target firmware and target database file in the building automation bus device. If both the database format verification and protocol stack testing pass, the burning of the building automation bus device is confirmed to be successful.

[0153] The target firmware refers to the firmware image that has been written into the building automation bus device and can be loaded by the device during startup. The target database file refers to the database file that has been written into the building automation bus device and is used by the protocol stack in the target firmware.

[0154] Database format verification is used to verify whether the target database file can be recognized and used by the protocol stack in the target firmware. Protocol stack testing is used to verify whether the protocol stack in the target building automation bus device can start normally and complete bus communication interaction.

[0155] Specifically, after the firmware and database files are burned, the host computer can read relevant information about the target firmware and target database files from the building automation bus device. Based on the reading results, it performs a database format verification on the target database file to confirm that the target database file is compatible with the protocol stack in the target firmware. If the verification result shows that the target database file meets the requirements of the protocol stack in the target firmware, the database format verification is considered successful; if the verification result shows that the target database file does not meet the requirements of the protocol stack in the target firmware, the database format verification is considered to have failed.

[0156] After the database format verification is passed, the host computer can perform a protocol stack test on the building automation bus device to confirm that the target firmware can perform normal bus communication after loading the target database file. If the test results show that the protocol stack can run normally and complete communication interaction, the protocol stack test is considered to have passed; if the test results show that the protocol stack cannot run normally or cannot complete communication interaction, the protocol stack test is considered to have failed.

[0157] After completing the database format verification and protocol stack test, if both the database format verification and protocol stack test are passed, the programming host computer can update the status of the building automation bus device to "programming successful" and upload the success record to the server or manufacturing execution system; if either test fails, the building automation bus device will be marked as "programming failed" and the reason for failure will be retained for rework or anomaly analysis.

[0158] The method for programming building automation bus devices provided in this application is applied to a building automation bus device programming system. The building automation bus device programming system includes a programming server and a programming host computer. The programming server first obtains the firmware and database files to be programmed, and then constructs a programming package based on the firmware and database files. The programming host computer obtains the programming package from the programming server and performs version compatibility verification on the firmware and database files in the programming package according to a preset compatibility matrix. If the version compatibility verification of the firmware and database files passes, the firmware and database files are programmed into the building automation bus device. After programming is completed, the programming host computer performs database format verification and protocol stack testing on the target firmware and target database files in the building automation bus device. If both the database format verification and protocol stack testing pass, the programming of the building automation bus device is determined to be successful.

[0159] This method binds firmware and database files at the production line task level using a programming server and constructs a unified programming package. The programming host computer performs version compatibility checks between the firmware and database files before writing, based on a compatibility matrix, and continues to perform database format checks and protocol stack tests after writing. This ensures that firmware and database file version matching confirmation, database format validity confirmation, and protocol stack communication function confirmation are all completed in a closed loop during the programming stage. In this way, the production line no longer relies on subsequent manual verification or whole-machine testing to discover problems such as version mismatch, abnormal database formats, or protocol stack communication failures. It can effectively block incompatible combinations before actual writing and promptly identify device states where the database is unresolvable or the protocol stack cannot communicate after writing. By moving version detection to the programming stage, it significantly reduces the whole-machine return rate caused by version incompatibility, reduces the labor costs, material losses, and production time occupied by rework, and avoids interference with the normal production rhythm during the rework process. This effectively shortens the production delivery cycle and enhances the controllability of batch programming operations.

[0160] The following is combined Figure 4 The process of constructing the flashing package is explained. Figure 4 This is a flowchart illustrating a method for constructing a programmable package according to an embodiment of this application. Figure 4 As shown, the method includes:

[0161] S401, The burning server determines the first verification benchmark value of the firmware and the second verification benchmark value of the database file.

[0162] After receiving the firmware and database files, the burning server can generate the corresponding first and second verification base values ​​synchronously or sequentially.

[0163] The first verification benchmark value is used to subsequently verify the integrity and consistency of the firmware image data. Since firmware typically contains multiple partition images, a corresponding verification benchmark value can be calculated for each partition image of the firmware. In this embodiment, since the subsequent verification methods for each partition image are similar, the verification benchmark values ​​corresponding to each partition image of the firmware are uniformly referred to as the first verification benchmark value, and will not be described separately below.

[0164] The second verification benchmark value is used to subsequently verify the integrity and consistency of the database file, that is, to verify whether the database file has been tampered with or damaged during transmission or storage.

[0165] The aforementioned verification benchmark values ​​can be implemented in the form of hash values, such as CRC32 values, MD5 values, or SHA values. By pre-calculating and recording these verification benchmark values, the original state of the firmware and database files can be verified in subsequent burning and comparison stages, thereby improving the reliability of the burning process.

[0166] S402. Construct a flashing package based on the first verification benchmark value, the second verification benchmark value, the firmware, and the database file.

[0167] After generating the first and second verification base values, the programming server can encapsulate these values ​​along with the corresponding firmware, database files, and their version information to form a programming package with a unique association. This programming package can include index fields, file address fields, and verification fields, enabling the programming host computer to directly parse the firmware and database file compatibility relationship after obtaining the programming package, and to complete integrity and consistency verification based on the verification base values.

[0168] For example, a corresponding verification field, such as android_fw_crc32(4B), can be built for the firmware in the header of the flashing package, with the value being the calculated CRC32 check value; a corresponding verification field, such as knx_db_crc32(4B), can be built for the database file, with the value being the corresponding CRC32 check value.

[0169] It should be noted that firmware typically contains multiple partition images, each with its own verification field. Here, only a single total field is used as an example; the construction method for the fields of each partition image is similar and will not be repeated here. Furthermore, the construction method for other specific fields in the flashing package can be found in step S302 of the aforementioned embodiments, and will not be repeated here.

[0170] This construction method binds firmware and database files to their corresponding verification base values ​​on the programming server side. The programming package carries verifiable association information during transmission, enabling subsequent reading, verification, and programming to be performed based on the same package. Since the verification base value corresponds one-to-one with the file content, when any file content changes, the corresponding verification base value changes synchronously, thus ensuring that the programming package accurately reflects the true state of the data to be written.

[0171] By using the above method, the flashing server completes the association and encapsulation of firmware, database files and related information when building the flashing package. This provides a stable basis for subsequent version compatibility verification, database format verification and protocol stack testing, making the pairing relationship of flashing objects clearer and improving the traceability and consistency of flashing results.

[0172] Based on the above embodiments, combined with Figure 5 and Figure 6 This document explains how to trigger the process of "how the host computer performs database format verification and protocol stack testing on the target firmware and target database file in the building automation bus device".

[0173] First, determine the first verification target value of the target firmware and the second verification target value of the target database file based on the data from the host computer; for example... Figure 5 As shown, when the first verification target value is consistent with the first verification benchmark value, and the second verification target value is consistent with the second verification benchmark value, database format verification and protocol stack testing are performed on the target firmware and target database file in the building automation bus device; for example... Figure 6 As shown, if the first verification target value is inconsistent with the first verification reference value, and / or the second verification target value is inconsistent with the second verification reference value, the step of burning the firmware and database file to the building automation bus device is re-executed, and this step is repeated until the first verification target value is consistent with the first verification reference value and the second verification target value is consistent with the second verification reference value, or until the maximum number of repetitions is reached, then the burning is determined to be abnormal, and the rework processing information of the building automation bus device is generated.

[0174] The first verification target value is used to characterize the verification result of the actual content burned after the target firmware is burned, that is, the verification value obtained by recalculating the target firmware burned into the building automation bus device. The second verification target value is used to characterize the verification result of the actual content burned after the target database file is burned, that is, the verification value obtained by recalculating the target database file burned into the building automation bus device.

[0175] In one implementation, the determination of the first and second verification target values ​​involves the host computer calling a command-line verification tool pre-installed in the system partition on the building automation bus device side via a command-line interaction interface. This tool reads the firmware partition images and the database file burned to / data / knx / db / knx_config.db, and performs a full calculation using a hash algorithm to obtain the values.

[0176] The command-line interaction interface is used to establish a command execution channel between the programming host computer and the building automation bus device, enabling the programming host computer to directly run programs in the file system on the building automation bus device side and obtain execution results.

[0177] This local verification method on the building automation bus device side avoids the large amount of data transmission of firmware and database files, and ensures that the verification value truly reflects the actual content of the storage area burned into the building automation bus device, effectively improving verification efficiency and data security.

[0178] The rework processing information is used to record abnormal equipment status, associate work order information, and output it to subsequent rework stations. The maximum number of repetitions limits the upper limit of reprogramming, and its value can be preset according to the production line cycle time and the rework strategy of building automation bus equipment.

[0179] After completing the firmware and database file burning, the host computer reads the written target firmware and target database file from the target device, calculates their checksums to obtain the first and second checksum target values, and compares them with the first and second checksum benchmark values ​​in the burning package. If both comparison results are consistent, it indicates that the firmware and database file have been completely and correctly burned to the target device. The host computer then continues to perform database format verification and protocol stack testing on the target database file. If either comparison is inconsistent, it indicates that a data error or transmission anomaly may have occurred during the burning process. The host computer then triggers re-burning control, re-parses the same burning package, and burns it to the target building automation bus device again until the comparison is consistent or the upper limit is reached. During re-burning, the host computer can clear the remnants of the previous burning in the building automation bus device and reissue the burning command to ensure that the data burned again is consistent with the burning package.

[0180] The process uses the consistency of the verification value as a prerequisite for judging the validity of the burning process, so that the database format verification and protocol stack test are only performed when the file pairing is consistent and the writing result is correct. When the verification is inconsistent, by limiting the number of repetitions and generating rework processing information, abnormal building automation bus devices can be separated from the normal production line in a timely manner and guided to the rework process, thereby effectively ensuring the burning quality and production efficiency of the production line.

[0181] The following is combined Figure 7 This document explains how to perform database format verification on the target firmware and target database file in the building automation bus device based on the data burned into the host computer. Figure 7 This is a flowchart illustrating a database format verification method provided in an embodiment of this application. Figure 7 As shown, the method includes:

[0182] S701, the host computer reads the minimum database format version supported by the protocol stack in the target firmware, as well as the format version of the target database file.

[0183] Among them, the minimum database format version supported by the protocol stack is used to characterize the lower limit of the database format versions that the protocol stack loaded by the target firmware can be compatible with, and the format version of the target database file is used to characterize the format level of the database file to be written, reflecting the version identifier of the table structure, field definition and data organization method of the data file.

[0184] In one implementation, the minimum database format version supported by the protocol stack in the target firmware can be stored in the version description area of ​​the firmware's partition image, for example, in the / system / build.prop file in the firmware's system partition image, recorded as the key-value pair ro.knx.stack.min_db_version. When the host computer parses the firmware, it reads the ro.knx.stack.min_db_version field in the / system / build.prop file within this description area, obtains its corresponding minimum database format version key-value pair, and converts it into a unified, comparable version encoding.

[0185] The format version of the target database file can be stored in the database file's metadata area. For example, in the aforementioned embodiment, the database file is burned to the location of the user data partition image in the firmware, such as / data / knx / db / knx_config.db. For instance, the host computer can parse the database file's metadata header (DB MetaHeader) from this path, extract the format version key value corresponding to the predefined format version field knx_db_format_version, and convert it into a comparable format version encoding for subsequent comparison and verification with the lowest version supported by the protocol stack.

[0186] S702. If the format version of the target database file is higher than or equal to the minimum database format version, then the database format verification is deemed to have passed.

[0187] After the flashing process is complete, the host computer can read the minimum database format version that the protocol stack can be compatible with from the version field preset in the target firmware, and read the corresponding format version from the header information or version identifier area of ​​the target database file. Then, it can compare the minimum database format version supported by the protocol stack with the format version of the target database file to obtain the verification result.

[0188] If the target database file's format version is higher than or equal to the minimum database format version (i.e., knx_db_format_version >= min_db_version), it means that the target database file's table structure, field definitions, and data organization are not lower than the minimum requirements that the protocol stack can support. For example, if the minimum database format version supported by the protocol stack in the firmware includes group address tables, personal address tables, communication object association tables, and routing filter tables, and the target database file's format version also supports all of the above table structures and has compatible field definitions, then the database format verification is considered successful.

[0189] The routing filter table is used to define the filtering rules for source address, destination address or message type when building automation bus devices forward messages. It is a key configuration structure to ensure bus communication security and data validity.

[0190] S703. If the format version of the target database file is lower than the minimum database format version, then the database format verification is determined to fail.

[0191] If the target database file's format version is lower than the minimum database format version (knx_db_format_version < min_db_version), it indicates that the target database file's table structure, field definitions, or data organization method falls below the minimum requirements for protocol stack operation. The protocol stack may fail to parse the database correctly or cause operational errors when loading it. For example, if the firmware's protocol stack supports a minimum database format version that includes a group address table, a personal address table, a communication object association table, and a route filtering table, but the target database file only supports the group address table, personal address table, and communication object association table, lacking the route filtering table, then the database format verification will fail.

[0192] Through the above-mentioned database format verification method, the host computer can determine in time during the burning stage whether the format version of the target database file meets the requirements of the protocol stack. This effectively avoids parsing errors or functional abnormalities in the building automation bus equipment due to format mismatch, reduces the probability of building automation bus equipment with such problematic files entering the subsequent testing stage, improves the verification capability of the burning process, and significantly improves the reliability of the burning results of the building automation bus equipment.

[0193] If the database format verification between the target firmware and the target database file fails during the burning of the host computer, and the target database file's format version is lower than the minimum database format version, then the database format verification is determined to have failed. Figure 8 As shown, the method may also include:

[0194] S801. Send a second instruction message to the burning server. The second instruction message is used to indicate that the database format verification failed.

[0195] When the database format verification fails, the programming host computer can encapsulate the verification failure status code, the mismatched format version information, and the relevant firmware and database file identifiers into a second indication information, and send the second indication information to the programming server through a preset interface to notify the programming server that there is a format version incompatibility problem between the current database file and the target firmware, so as to facilitate subsequent processing on the programming server side.

[0196] S802. The burning server updates the format version of the database file according to the second instruction information, or updates the firmware protocol stack to update the minimum database format version supported by the firmware protocol stack, and rebuilds the burning package.

[0197] After receiving the second instruction information, the burning server can update the format and version of the database file through the manufacturing execution system to make the database file meet the protocol stack requirements of the target firmware. When the database file cannot be directly upgraded, the burning server can switch or refresh the protocol stack program corresponding to the firmware and update the minimum database format version supported by the protocol stack simultaneously. Then, the burning package is rebuilt based on the updated firmware or database file and sent to the burning host computer to execute the subsequent burning process again.

[0198] This processing method enables the database format verification result to be fed back to the burning server, which then corrects the database file version or adapts the protocol stack before regenerating the burning package. This ensures that the minimum database format version supported by the firmware's protocol stack matches the database file format version, significantly reducing the probability of repeated burning, production interruptions, and rework caused by inconsistent format versions, and improving the automation level of the burning process and overall production efficiency.

[0199] The following is combined Figure 9 This document explains how to perform protocol stack testing on the target firmware and target database file of a building automation bus device based on the programming of the host computer. Figure 9 This is a flowchart illustrating a protocol stack testing method provided in an embodiment of this application. Figure 9 As shown, the method includes:

[0200] S901: The host computer sends a start command to the building automation bus device to start the protocol stack of the building automation bus device.

[0201] The host computer can establish a communication connection with the building automation bus device via USB, Ethernet, or serial port. The startup command is sent to the building automation bus device through this communication connection. After receiving the startup command, the building automation bus device starts its protocol stack and reads the programmed target database file to complete the initialization configuration required for the protocol stack to run.

[0202] For example, after the protocol stack starts, it can read the burned database file, i.e. the target database file, from the preset path such as the target location where the database file is burned in the aforementioned embodiment, / data / knx / db / knx_config.db, and complete the loading of the target database file and the initialization of the protocol stack.

[0203] After the protocol stack initialization is complete, it can notify the programming host computer via the ioctl interface (such as the IOCTL_KNX_INIT_DONE command) provided by the Hardware Abstraction Layer (HAL) that the database file initialization is complete, indicating that the building automation bus device is ready to receive and process bus messages. The ioctl interface is a kernel-based interface used for driver control and status interaction of the building automation bus device. In this embodiment, the ioctl interface serves as an event notification channel between the protocol stack and the programming host computer, reporting status changes on the building automation bus device side to the programming host computer so that the programming host computer can coordinate subsequent testing procedures accordingly.

[0204] S902, Send a broadcast message to the bus of the building automation bus device.

[0205] After receiving notification that the database file initialization is complete, the host computer generates a broadcast message according to a preset message format and sends the broadcast message to the bus where the building automation bus device is located. The broadcast message is used to trigger the protocol stack response of the building automation bus device. Through bus interaction scenarios, it verifies whether the communication functions of protocol stack message reception, parsing, and response are normal. The preset message format can be the standard KNX bus broadcast message format or a custom bus test message format. This application embodiment does not limit this and can be flexibly adapted according to the actual test scenario and test requirements.

[0206] For example, the host computer can call the bus detection tool through the command line interface to send a broadcast message to the bus of the building automation bus device. The format of the broadcast message can be configured as: L_DATA.ind, target address: 0 / 0 / 0 (indicating group address 0 / 0 / 0, i.e., global broadcast address), APDU: GroupValueRead (indicating application layer group value read request).

[0207] Among them, the bus detection tool is a test tool adapted to the design of building automation bus. It supports standardized sending of bus messages, interactive response detection, and capture and analysis of bus data, which makes it convenient for the host computer to verify the bus communication behavior and troubleshoot during the burning or debugging process.

[0208] "L_DATA.ind" is an instruction from the data link layer to report the received broadcast message to the application layer of the protocol stack. In this embodiment, the host computer is not programmed based on real bus signals. Instead, a virtual received message is injected into the protocol stack by constructing and issuing the L_DATA.ind command, so as to verify the processing logic of the protocol stack without the need for an external bus device.

[0209] In the building automation bus protocol, "Destination Address: 0 / 0 / 0" is a global broadcast address. Messages sent to this address will be received and processed by all devices on the bus that are in monitoring mode. In this embodiment, using this address allows the protocol stack to verify its ability to process broadcast messages without specifying a specific device address, thereby simplifying the testing process.

[0210] "APDU: GroupValueRead" represents a group value read command in the application layer protocol data unit of the protocol stack, used to request the device on the bus to read the current value of a specified group address. In this embodiment, when the protocol stack receives a broadcast message, it should look up the configuration information of the corresponding group address based on the loaded target database file and return the corresponding acknowledgment response or current value response to verify whether the database file is loaded correctly and whether the application layer logic of the protocol stack is working properly.

[0211] S903. If an acknowledgment response from the protocol stack is received within the preset time, the protocol stack test is considered successful.

[0212] The host computer starts a timer immediately after sending the broadcast message. The preset time can be set according to the typical response latency of bus communication and the processing capability of the building automation bus device. For example, it can be set to 3 seconds or 5 seconds. This embodiment does not limit this in detail. In actual application, it can be adjusted according to the network conditions of the test environment and the performance of the building automation bus device.

[0213] Within a preset time period, the host computer continuously monitors the acknowledgment messages returned by the building automation bus devices. These acknowledgment messages typically contain a normal response from the protocol stack to the GroupValueRead request, such as returning the value of the current group address or returning an ACK flag acknowledging that the message was received and processed correctly. When the host computer receives an acknowledgment message containing the aforementioned acknowledgment flags, it determines that the protocol stack test was successful, meaning the protocol stack initialization was successful, indicating that the protocol stack function in the target firmware has been started normally and has bus communication capabilities.

[0214] In one implementation, the programming host computer can capture the ACK response by monitoring the ACK callback in the protocol stack. The ACK callback is an event notification interface triggered by the protocol stack when it receives an ACK response from the building automation bus device and sends it to the upper-layer application. By registering this callback function with the protocol stack in advance, the programming host computer can be automatically woken up and obtain the response content when the ACK arrives, without needing continuous polling or passive waiting.

[0215] For example, a logging tool can be used to parse system logs containing the "KNX_STACK_ACK" flag. When this flag appears in the log, it is considered that an ACK response has been received, thereby confirming that the protocol stack's processing flow for broadcast messages is complete and error-free.

[0216] S904. If no acknowledgment is received within the preset time, or if a negative acknowledgment is received from the protocol stack within the preset time, the protocol stack test is determined to have failed.

[0217] If no acknowledgment is received by the preset time, or if a negative response with an error code, rejection code, or other abnormal identifier is received within the preset time, the protocol stack test is deemed to have failed, i.e., the protocol stack initialization has failed. This indicates that the target firmware may have problems such as protocol stack configuration errors, bus interface abnormalities, or incomplete processing logic.

[0218] After the host computer determines a timeout or receives a negative response, it can generate the corresponding test results and record them in the programming log. It can also include the reasons for failure, such as timeout, NACK, error code, etc., which facilitates subsequent problem localization and analysis, and provides a basis for troubleshooting for R&D or testing personnel.

[0219] This method, by starting the protocol stack after programming and then sending a broadcast message to the bus and judging based on the response status, enables the target firmware and target database file to undergo communication availability verification before subsequent delivery. This confirms whether the protocol stack can respond normally during the programming stage. This not only ensures that test results and programming results are output synchronously, improving the certainty of the status judgment of building automation bus devices after programming, but also effectively reduces the risk of on-site deployment rework due to protocol stack anomalies.

[0220] After a timeout, the host computer generates test results and records them in the programming log. By starting the protocol stack after programming, sending a broadcast message to the bus, and judging the response status, the target firmware and target database file can undergo communication availability verification before subsequent delivery. This method can directly confirm whether the protocol stack can respond normally during the programming stage, thus synchronizing the test results with the programming results and improving the certainty of device status judgment after programming.

[0221] Furthermore, after completing the aforementioned programming verification process, the programming host computer can summarize the programming information generated at each stage and upload the programming records to the production line manufacturing execution system via a preset interface such as post / api / v1 / flash_records. Simultaneously, a programming report is generated to achieve traceability and centralized management of production data. This programming report includes, but is not limited to, the following fields: building automation bus device serial number, programming time, firmware version, database version, version compatibility verification result, database format verification result, protocol stack test result, hash values ​​at each stage, and hash value verification results.

[0222] Figure 10 This is a schematic diagram of a building automation bus device programming system provided as an embodiment of this application. Figure 10 As shown, the building automation bus device programming system 1000 includes: a programming server 1001 and a programming host computer 1002;

[0223] The burning server 1001 obtains the firmware and database file to be burned; the firmware is an executable program image used for the operation of building automation bus devices, and the database file is a parameter description file used for communication and function configuration of building automation bus devices.

[0224] The programming server 1001 builds a programming package based on the firmware and database files;

[0225] The host computer 1002 obtains the burning package from the burning server 1001 and performs version compatibility verification on the firmware and database files in the burning package according to the preset compatibility matrix. If the version compatibility verification of the firmware and database files passes, the firmware and database files are burned to the building automation bus device.

[0226] Once the burning process is complete, the burning host computer 1002 performs database format verification and protocol stack testing on the target firmware and target database file in the building automation bus device. If both the database format verification and protocol stack testing pass, the burning of the building automation bus device is confirmed to be successful.

[0227] In some implementations, the host computer 1002 is programmed for:

[0228] Read the minimum database format version supported by the protocol stack in the target firmware, as well as the format version of the target database file;

[0229] If the target database file's format version is higher than or equal to the minimum database format version, then the database format verification is considered successful.

[0230] If the target database file's format version is lower than the minimum database format version, then the database format verification fails.

[0231] In some implementations, the host computer 1002 is programmed for:

[0232] Send a start command to the building automation bus device to start the protocol stack of the building automation bus device;

[0233] Send a broadcast message to the bus of the building automation bus device;

[0234] If a confirmation response from the protocol stack is received within the preset time, the protocol stack test is considered successful.

[0235] If no acknowledgment is received within the preset time, or if a negative acknowledgment is received from the protocol stack within the preset time, the protocol stack test is deemed to have failed.

[0236] In some implementations, the programming server 1001 is used for:

[0237] Determine the first verification benchmark value of the firmware and the second verification benchmark value of the database file;

[0238] The flashing package is constructed based on the first verification benchmark value, the second verification benchmark value, the firmware, and the database file.

[0239] In some implementations, the host computer 1002 is programmed for:

[0240] Determine the first verification target value of the target firmware and the second verification target value of the target database file; if the first verification target value is consistent with the first verification benchmark value and the second verification target value is consistent with the second verification benchmark value, perform database format verification and protocol stack testing on the target firmware and target database file in the building automation bus device; if the first verification target value is inconsistent with the first verification benchmark value and / or the second verification target value is inconsistent with the second verification benchmark value, re-execute the step of burning the firmware and database file to the building automation bus device, and repeat this step until the first verification target value is consistent with the first verification benchmark value and the second verification target value is consistent with the second verification benchmark value, or until the maximum number of repetitions is reached, then determine that the burning is abnormal, and generate the rework processing information of the building automation bus device.

[0241] In some implementations, the host computer 1002 is programmed for:

[0242] If the firmware and database file version compatibility check fails, a first indication message is sent to the burning server 1001. The first indication message is used to indicate that the firmware and database file version compatibility check failed.

[0243] The burning server 1001 updates the firmware or database file based on the first instruction information and rebuilds the burning package.

[0244] In some implementations, the host computer 1002 is programmed for:

[0245] The compatibility matrix is ​​obtained from the manufacturing execution system through a preset interface.

[0246] In some implementations, the host computer 1002 is programmed for:

[0247] If the database format verification of the target firmware and the target database file fails, a second indication message is sent to the burning server 1001. The second indication message is used to indicate that the database format verification failed.

[0248] According to the second instruction information, the burning server 1001 updates the format version of the database file, or updates the firmware protocol stack to update the minimum database format version supported by the firmware protocol stack, and rebuilds the burning package.

[0249] The building automation bus device programming system provided in this application embodiment can execute the technical solution shown in the above method embodiment. Its implementation principle and beneficial effects are similar, and will not be repeated here.

[0250] Figure 11 This is a schematic diagram of the structure of an electronic device provided for an exemplary embodiment of this application. Please refer to... Figure 11 The electronic device 1100 may include at least one processor 1101 for implementing the programming method of the building automation bus device provided in the embodiments of this application.

[0251] Optionally, the electronic device 1100 further includes at least one memory 1102 for storing program instructions and / or data. The memory 1102 is coupled to the processor 1101. The coupling in this embodiment is an indirect coupling or communication connection between devices, units, or modules, and can be electrical, mechanical, or other forms, used for information exchange between devices, units, or modules. The processor 1101 may operate in conjunction with the memory 1102. The processor 1101 may execute program instructions stored in the memory 1102. At least one of the at least one memory may be included in the processor.

[0252] Optionally, the electronic device 1100 further includes a communication interface 1103 for communicating with other devices via a transmission medium, thereby enabling the electronic device 1100 to communicate with other devices. The communication interface 1103 may be, for example, a transceiver, interface, bus, circuit, or a device capable of transmitting and receiving functions. The processor 1101 can utilize the communication interface 1103 to transmit and receive data and / or information, and to implement the methods provided in the embodiments of this application. For details, please refer to the detailed descriptions in the preceding embodiments; further elaboration is not required here.

[0253] This application embodiment does not limit the specific connection medium between the processor 1101, memory 1102, and communication interface 1103. This application embodiment... Figure 11 The processor 1101, memory 1102, and communication interface 1103 are connected via bus 1104. Bus 1104 is... Figure 11 The connections between other components are shown in thick lines only and are not intended to be limiting. This bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, Figure 11 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0254] It should be understood that the processor in the embodiments of this application can be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method embodiments can be completed by the integrated logic circuits in the processor's hardware or by instructions in software form. The processor can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory, and the processor reads the information in the memory and, in conjunction with its hardware, completes the steps of the above method.

[0255] It should also be understood that the memory in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (SLDRAM), and direct rambus RAM (DR RAM). It should be noted that the memory used in the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0256] Accordingly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the methods described in the above-described method embodiments.

[0257] Accordingly, embodiments of this application may also provide a computer program product, which includes a computer program that, when executed by a processor, can implement the methods shown in the above-described method embodiments.

[0258] The terms “unit”, “module”, etc., used in this specification may be used to refer to computer-related entities, hardware, firmware, combinations of hardware and software, software, or software in execution.

[0259] Those skilled in the art will recognize that the various illustrative logical blocks and steps described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application. In the several embodiments provided in this application, it should be understood that the disclosed apparatus, devices, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for example, the division of units is merely a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the shown or discussed mutual couplings or direct couplings or communication connections may be through some interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0260] The unit described as a separate component may or may not be physically separate. The component shown as a unit may or may not be a physical unit; that is, it may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0261] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0262] In the above embodiments, the functions of each functional unit can be implemented entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. This computer program product includes one or more computer instructions (programs). When the computer program instructions (programs) are loaded and executed on a computer, all or part of the flow or function described in the embodiments of this application is generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., digital video discs (DVDs)), or semiconductor media (e.g., solid-state disks (SSDs)).

[0263] If this function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0264] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for programming building automation bus equipment, characterized in that, An application to a building automation bus device programming system, the building automation bus device programming system including a programming server and a programming host computer, the method comprising: The burning server acquires the firmware and database file to be burned; the firmware is an executable program image for the operation of the building automation bus device, and the database file is a parameter description file for the communication and function configuration of the building automation bus device. The burning server constructs a burning package based on the firmware and the database file; The programming host computer obtains the programming package from the programming server and performs version compatibility verification on the firmware and the database file in the programming package according to the preset compatibility matrix. If the version compatibility verification of the firmware and the database file passes, the firmware and the database file are programmed into the building automation bus device. Once the burning process is complete, the burning host computer performs database format verification and protocol stack testing on the target firmware and target database file in the building automation bus device. If both the database format verification and protocol stack testing pass, the burning of the building automation bus device is confirmed to be successful.

2. The method according to claim 1, characterized in that, The host computer for programming performs database format verification on the target firmware and target database file in the building automation bus device, including: The host computer reads the minimum database format version supported by the protocol stack in the target firmware, as well as the format version of the target database file; If the format version of the target database file is higher than or equal to the minimum database format version, then the database format verification is deemed successful. If the format version of the target database file is lower than the minimum database format version, then the database format verification is determined to fail.

3. The method according to claim 1, characterized in that, The host computer performs protocol stack testing on the target firmware and target database file in the building automation bus device, including: The programming host computer sends a start command to the building automation bus device to start the protocol stack of the building automation bus device; Send a broadcast message to the bus of the building automation bus device; If a confirmation response from the protocol stack is received within the preset time, the protocol stack test is considered successful. If no confirmation response is received within the preset time, or if a negative response from the protocol stack is received within the preset time, the protocol stack test is determined to have failed.

4. The method according to any one of claims 1-3, characterized in that, The burning server constructs a burning package based on the firmware and the database file, including: The burning server determines a first verification benchmark value for the firmware and a second verification benchmark value for the database file; The flashing package is constructed based on the first verification benchmark value, the second verification benchmark value, the firmware, and the database file.

5. The method according to claim 4, characterized in that, The host computer performs database format verification and protocol stack testing on the target firmware and target database file in the building automation bus device, including: The host computer determines a first verification target value for the target firmware and a second verification target value for the target database file. If the first verification target value matches the first verification benchmark value, and the second verification target value matches the second verification benchmark value, the host computer performs database format verification and protocol stack testing on the target firmware and target database file in the building automation bus device. If the first verification target value does not match the first verification benchmark value, and / or the second verification target value does not match the second verification benchmark value, the step of burning the firmware and the database file to the building automation bus device is re-executed, and this step is repeated until the first verification target value matches the first verification benchmark value, and the second verification target value matches the second verification benchmark value, or until the maximum number of repetitions is reached. If so, a burning error is determined, and rework information for the building automation bus device is generated.

6. The method according to any one of claims 1-3, characterized in that, The method further includes: If the firmware and the database file version compatibility check fails, the burning host computer sends a first indication message to the burning server. The first indication message is used to indicate that the firmware and the database file version compatibility check failed. The burning server updates the firmware or the database file based on the first instruction information and reconstructs the burning package.

7. The method according to any one of claims 1-3, characterized in that, The method further includes: The programming host computer obtains the compatibility matrix from the manufacturing execution system through a preset interface.

8. The method according to any one of claims 1-3, characterized in that, The method further includes: If the database format verification between the target firmware and the target database file fails, the burning host computer sends a second indication message to the burning server. The second indication message is used to indicate that the database format verification failed. The burning server updates the format version of the database file or updates the protocol stack of the firmware according to the second instruction information to update the minimum database format version supported by the protocol stack of the firmware, and reconstructs the burning package.

9. A building automation bus device programming system, characterized in that, The building automation bus device programming system includes: a programming server and a programming host computer; The burning server acquires the firmware and database file to be burned; the firmware is an executable program image for the operation of the building automation bus device, and the database file is a parameter description file for the communication and function configuration of the building automation bus device. The burning server constructs a burning package based on the firmware and the database file; The host computer obtains the burning package from the burning server and performs version compatibility verification on the firmware and database file in the burning package according to the preset compatibility matrix. If the version compatibility verification of the firmware and database file passes, the firmware and database file are burned to the building automation bus device. Once the burning process is complete, the burning host computer performs database format verification and protocol stack testing on the target firmware and target database file in the building automation bus device. If both the database format verification and protocol stack testing pass, the burning of the building automation bus device is confirmed to be successful.

10. An electronic device, characterized in that, The electronic device includes: At least one processor; and a memory communicatively connected to said at least one processor; The memory stores instructions that can be executed by the at least one processor to cause the electronic device to perform the method as described in any one of claims 1-8.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, implement the method as described in any one of claims 1-8.

12. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the method as described in any one of claims 1-8.

Images