A method and system for parsing and safely writing PLC engineering files for large language models

Abstract

The application discloses a PLC engineering file analysis and safe direct writing editing method and system for a large language model, and belongs to the technical field of industrial automation and artificial intelligence. The method comprises the following steps: decompressing a target PLC engineering file and identifying member files in the target PLC engineering file; pairing multiple database files belonging to the same program group based on program group identification to generate a program group mapping relationship; obtaining programming software runtime cache data, and establishing a bidirectional mapping with the member files to generate a cache comparison report; generating a structured report containing a forced read sequence constraint based on the program group mapping relationship and the cache comparison report; reading the structured report according to the forced read sequence by a large language model and generating a modification plan; performing database direct writing and integrity checking under whitelist constraint, and rolling back when the checking fails; and re-packaging the engineering file and auditing. The application realizes safe and automatic modification of a PLC engineering file by a non-professional person through a natural language, and does not need to depend on a manufacturer software.

Description

Technical Field

[0001] This invention belongs to the field of interdisciplinary technology of industrial automation and artificial intelligence, specifically relating to a method and system for parsing and safely writing PLC project files for large language models. Background Technology

[0002] Programmable Logic Controllers (PLCs) are widely used in industrial automation. Their engineering files contain core data such as ladder diagram programs, equipment comments, and hardware configurations, making them an important component of industrial control systems. However, existing technologies have significant shortcomings in the following three aspects: 1. PLC project files are stored in a closed format, making them difficult for non-professionals to access. Mainstream PLC programming software uses proprietary, closed formats to store project files, and the internal structure and database organization of these files are not publicly available. Users must rely on proprietary software provided by the manufacturer to open, view, or edit the project content. For maintenance personnel, project managers, or system integrators without PLC programming backgrounds, understanding and modifying PLC projects is extremely difficult, severely hindering operational efficiency in industrial settings. Currently, there are no tools available for non-professional users to extract and readablen PLC project content.

[0003] 2. Large language models cannot directly process PLC engineering data, resulting in a gap in human-computer interaction. While large language models possess significant capabilities in code understanding, natural language interaction, and automated reasoning, existing PLC engineering files are stored in closed binary or proprietary database formats, making it impossible for large language models to directly read and understand their content. The lack of standard interfaces and methods for structuring and transforming PLC engineering data and making it accessible to large language models hinders the implementation of AI-assisted PLC program understanding and modification applications.

[0004] 3. PLC program modification relies on vendor software and lacks a programmable, secure direct-write mechanism. Currently, PLC program modifications must be completed through vendor-specific development environments, involving cumbersome procedures and making batch execution via programming or automated AI-driven processes impossible. There is currently no systematic method for directly writing to databases embedded in PLC project files, nor is there an effective mechanism to ensure data integrity and project file legitimacy during the direct-write process, thus hindering the engineering application of automated PLC program modification. Summary of the Invention

[0005] This invention aims to provide a method and system for parsing and securely writing PLC project files for large language models, in order to solve the problems of existing technologies where PLC project files have closed formats, making it difficult for non-professionals to intervene, large language models cannot directly process the PLC project file data, there are gaps in human-computer interaction, and the modification of PLC project files depends on vendor software and lacks a programmable secure direct writing mechanism.

[0006] To achieve the above objectives, the present invention provides the following technical solution: A method for parsing and safely writing PLC project files for large language models includes the following steps: S1: Decompress the target PLC project file as a compressed container, identify the member files, and obtain a list of member files; the member files include database files, binary compilation artifacts, and hardware configuration files; S2: Based on the program group identifier in the filename of each of the database files, pair up multiple database files belonging to the same program group to generate a program group mapping relationship; S3: Start the programming software corresponding to the PLC project file, obtain the runtime cache data generated when the PLC project file is loaded by the programming software, establish a bidirectional mapping relationship between each member file in the member file list and the file with the same name in the cache data, and generate a cache comparison report; S4: Generate a structured report based on the program group mapping relationship and the cache comparison report. The structured report includes a mandatory read order constraint, which is used to limit the order in which the large language model reads each data file in the structured report. S5: The large language model reads each data file in the structured report according to the mandatory reading order constraint, generates a modification plan based on the natural language modification intent, and performs a legality verification on the modification plan; S6: According to the modification plan that has passed the legality check, perform a database direct write operation on the PLC project file. The database direct write operation only writes to the database file, keeping the original bytes of the binary compilation product and the hardware configuration file unchanged, and only allowing the writing of program blocks of the write-allowed type to obtain the modified database file. Perform an integrity check on the modified database file. If the check passes, the modified database file is synchronously replaced back into the compressed container of the PLC project file according to the member mapping relationship in the cache comparison report. If the check fails, roll back to the state before modification. S7: Repackage the updated project file into a PLC project file and record the audit log.

[0007] Preferably, the step of pairing multiple database files belonging to the same program group based on the program group identifier in the filenames of each database file to generate a program group mapping relationship includes: the database files include a ladder diagram database, a variable database, and a step information database; the program group identifier is a hash prefix in the filenames of the database files; using the hash prefix in the filenames of each database file as the association key, the ladder diagram database, the variable database, and the step information database under the same hash prefix are grouped into one program group; the total number of ladder diagram physical blocks in the ladder diagram database is compared with the number of steps... The total number of registered blocks in the information database is compared to verify the correctness of the merging. The total number of ladder diagram physical blocks is the actual number of program logic blocks stored in the ladder diagram database, and the total number of registered blocks is the number of step indexes recorded in the step information database. The total number of ladder diagram physical blocks from the same program group should be consistent with the total number of registered blocks. When the total number of ladder diagram physical blocks is consistent with the total number of registered blocks, the merging is confirmed as correct, and the program group mapping relationship is generated. When the total number of ladder diagram physical blocks is inconsistent with the total number of registered blocks, an alarm is triggered, and write operations are prohibited for that program group.

[0008] Preferably, the step of obtaining runtime cache data generated when the PLC project file is loaded by the programming software includes: recording the status of all existing session directories in the cache root directory of the programming software to form a baseline snapshot; opening the PLC project file through the system default associated program, triggering the programming software to load the PLC project file and write runtime cache data to the cache directory of the programming software; polling and monitoring the cache root directory at 0.5-second intervals to identify session directories added after the baseline snapshot or whose latest modification time has changed; and for the identified session directories, calculating the number of files, cumulative bytes, and latest modification time based on their file count, cumulative bytes, and latest modification time. A steady-state determination is performed. When the number of files, the cumulative number of bytes, and the latest modification time remain unchanged for 8 consecutive seconds and the total waiting time is not less than 10 seconds, it is determined that the cache writing of the session directory is complete and the session directory has reached a steady state. A second steady-state determination is performed separately on the target project subdirectory in the session directory. When the number of files, the cumulative number of bytes, and the latest modification time of the target project subdirectory remain unchanged for 8 consecutive seconds, it is determined that the cache writing of the target project subdirectory is complete and the target project subdirectory has reached a steady state. The programming software process started this time is closed. The session directory is copied to the workspace as the runtime cache data.

[0009] Preferably, the forced read order constraint is implemented in the following ways: by binding a unique entry path, the read requests of the large language model are limited to being initiated only through a unified entry point; by using a read status serial lock, multiple read requests are executed in a preset order; by using a pre-order check, the structured report to be read in the current request is checked before each read request is executed to see if it conforms to the structured report that should be read in the preset order; and by using a read time sequence log verification, the timestamp and report identifier of the read request are recorded.

[0010] Preferably, the legality verification of the modification plan includes: performing an allowed type verification on the program block type of each write operation in the modification plan to confirm whether the program block type of each write operation in the modification plan belongs to the allowed write type program block; if it belongs, the verification passes; if it does not belong, the verification fails; confirming whether the file name of the target database file in the modification plan is consistent with the program group structure record in the structured report; if they are consistent, the verification passes; if they are inconsistent, the verification fails; verifying whether the device address in the modification plan is within a valid range, the valid range including the address range of the soft components officially specified by the PLC for the corresponding model of the PLC project file and the actual hardware allocation address of the local machine recorded in the hardware configuration file; if it is within the valid range, the verification passes; if it exceeds the range, the verification fails.

[0011] Preferably, the program blocks that are allowed to be written include real ladder diagram blocks with blocktype=0 and END termination blocks with blocktype=5; line comment blocks with blocktype=1 and header blocks with blocktype=2 are prohibited from being written; the END termination blocks allow for position updates of existing END termination blocks, or allow for the addition of an END termination block when it is missing, but prohibit the addition of multiple END termination blocks.

[0012] Preferably, the step of performing integrity verification on the modified database files includes: performing a PRAGMA integrity_check on each modified database file to confirm whether the internal structure of the database file is complete; determining that the verification is successful when all database files return ok; and triggering a full rollback to the state before modification when any database file returns an exception.

[0013] This invention also provides a PLC project file parsing and safe direct-write editing system for large language models, comprising: The container parsing module is configured to decompress the target PLC project file as a compressed container, identify the member files within it, and obtain a list of member files; the member files include database files, binary compilation artifacts, and hardware configuration files. The program group pairing module is configured to pair multiple database files belonging to the same program group based on the program group identifier in the file name of each database file, thereby generating a program group mapping relationship. The cache capture and mapping module is configured to launch the programming software corresponding to the PLC project file, obtain the runtime cache data generated when the PLC project file is loaded by the programming software, establish a bidirectional mapping relationship between each member file in the member file list and the file with the same name in the cache data, and generate a cache comparison report. The structured report generation module is configured to generate a structured report based on the program group mapping relationship and the cache comparison report. The structured report includes a mandatory read order constraint, which is used to limit the order in which the large language model reads each data file in the structured report. The large language model decision module is configured to have the large language model read each data file in the structured report according to the mandatory reading order constraint, generate a structured modification plan based on the natural language modification intent, and perform a legality check on the structured modification plan; The secure direct write and verification module is configured to perform a database direct write operation on the PLC project file according to the structured modification plan that has passed the legality verification. The database direct write operation only performs writing on the database file, keeping the original bytes of the binary compilation product and the hardware configuration file unchanged, and only allowing the writing of program blocks of the write-allowed type to obtain the modified database file. The module then performs an integrity verification on the modified database file. If the verification passes, the modified database file is synchronously replaced back into the compressed container of the PLC project file according to the member mapping relationship in the cache comparison report. If the verification fails, the system rolls back to the state before modification. The encapsulation and auditing module is configured to re-encapsulate the updated project files into PLC project files and record audit logs.

[0014] Preferably, when the secure direct write and verification module performs a database direct write operation, it only allows writing real ladder diagram blocks with a blocktype value of 0 and END termination blocks with a blocktype value of 5, and refuses to write line comment blocks with a blocktype value of 1 and header blocks with a blocktype value of 2; the END termination block allows updating the position of existing END termination blocks, or adding an END termination block when it is missing, but prohibits adding multiple END termination blocks.

[0015] The present invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method described in any of the above technical solutions.

[0016] Compared with the prior art, the present invention has the following advantages: 1. Breaking down the barriers of closed formats significantly lowers the barrier to understanding PLC engineering. Existing technologies require operators to have PLC expertise and rely on vendor-specific software to view engineering content. This invention, through independently developed parsing software, transforms closed-format PLC engineering files into standardized structured data. This allows maintenance personnel, managers, and system integrators without PLC programming backgrounds to quickly obtain core engineering information such as ladder diagram program structure, equipment annotations, and hardware configurations without installing or operating vendor software, significantly reducing the operation and maintenance threshold in industrial settings.

[0017] 2. Achieving effective integration of large language models and PLC engineering data. Existing technologies cannot directly read and understand PLC engineering file content, resulting in a lack of data foundation for AI-assisted PLC programming. This invention provides a PLC engineering data interface that can be directly consumed by the large language model by establishing a structured report system and a mandatory read order constraint mechanism. The mandatory read order is implemented through program-level hard rules such as unique entry path binding, read status serial locking, pre-order verification, and timing log verification, forcing the large language model to read structured reports in a preset order, thus reducing comprehension bias caused by missing context. This enables the large language model to accurately understand ladder diagram semantics, interpret equipment logic, and transform natural language instructions from non-professional users into executable program modification schemes, realizing human-machine natural language interaction in the field of industrial control programming.

[0018] 3. Enables secure direct writing and editing of PLC project files without vendor software, supporting automated modification processes. Existing technologies require manual operation through the vendor's development environment for any modification to PLC project files, making programmatic or automated execution impossible. This invention achieves program modification by directly manipulating the embedded database within the project file. Combined with block type legality whitelists, device address range verification, and integrity verification mechanisms, it ensures the legality of modified data and the identifiability of the project file. The entire modification process does not overwrite the original file; instead, it exports a new file, ensuring operational security and traceability. This provides an engineered implementation path for batch modification and AI-automated editing of PLC programs.

[0019] 4. The three core technologies work together to form a complete closed loop, demonstrating strong engineering applicability. The parsing software, the large language model access mechanism, and the direct database writing and editing technologies complement each other, forming a complete technical closed loop from reading engineering files and AI understanding and decision-making to safe program modification. This has been verified in actual industrial PLC engineering projects. The modified engineering files have passed the verification and compilation by programming software, proving that this invention has practical engineering value for direct application. Attached Figure Description

[0020] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the accompanying drawings used in the embodiments are briefly described below: Figure 1 This is a flowchart illustrating the PLC project file parsing and secure direct-write editing method for large language models according to an embodiment of the present invention. Figure 2 This is a module architecture diagram of a PLC project file parsing and secure direct writing editing system for large language models, according to an embodiment of the present invention. Detailed Implementation

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

[0022] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains.

[0023] It should be noted that the core mechanism of this invention does not depend on specific programming software. The method of this invention can be applied to any PLC project file that uses a compressed container with an embedded database architecture and contains program block indexes and step indexes. The following embodiments use PLC project files with proprietary encapsulation formats as examples, but the scope of protection of this invention is not limited to these specific embodiments.

[0024] The specific embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0025] Example 1: Complete Process of PLC Project File Parsing and Secure Direct Write Editing See Figure 1 This invention provides a method for parsing and safely writing PLC project files for large language models. In one embodiment, it includes the following steps: S1: Container parsing step. Decompress the target PLC project file as a compressed container, identify the member files within it, and obtain a list of member files; the member files include database files, binary compilation artifacts, and hardware configuration files.

[0026] In some embodiments, the target PLC project file is a PLC project file with a proprietary encapsulation format, the compressed container is a ZIP format container, and the database file is an SQLite format database file. The parsing software opens the target project file as a standard ZIP compressed package, traverses all member files, and classifies the members into three categories according to their name suffixes: SQLite database files (including ladder diagram database, variable database, step information database, equipment annotation database, tag database, etc.), binary compilation artifacts, and hardware configuration files. The binary compilation artifacts are automatically generated by the programming software during compilation, and this invention does not manually modify them.

[0027] In some embodiments, the following operations are performed synchronously in a multi-threaded concurrent manner on all SQLite database files: reading the row count and column structure of each table; counting the number of blocks of each type in the LadderBlocks table of the ladder diagram database by the blocktype field; querying the DEVICE_DATA and COMMENT_DATA tables in the device annotation database to extract all device annotations; performing PRAGMA integrity_check on all SQLite files to confirm file integrity; and calculating the SHA-256 hash value of each ZIP member as a change tracking benchmark.

[0028] S2: Program group pairing step. Based on the program group identifier in the filename of each database file, multiple database files belonging to the same program group are paired to generate a program group mapping relationship.

[0029] In some embodiments, the program group is identified by a hash prefix in the filename of the database file. Using the hash prefix of each database filename as the association key, ladder diagram databases, variable databases, and step information databases under the same hash prefix are grouped into one program group. This hash prefix is ​​a unique identifier for the program group pre-generated within the PLC engineering development software, and is not obtained by calculating SHA-256 in this system; routine program logic editing will not change this prefix, and a new prefix will only be generated when adding, reorganizing, or rebuilding program units.

[0030] Example: A project file contains three database files with filenames 722a996de5bb097b_LDDB.db, 722a996de5bb097b_MilDB.db, and 722a996de5bb097b_StepInfo.db. All three have the same hash prefix of 722a996de5bb097b. The parsing software groups them into a program group and establishes a mapping relationship between this program group and the three database files.

[0031] In some embodiments, pairing employs a two-level verification process: first, the ladder diagram database, variable database, and step information database under the same hash prefix are grouped into a single program group using the hash prefix as the association key; then, the total number of ladder diagram physical blocks in the ladder diagram database is compared with the total number of registered blocks in the step information database. If they match, the merging is confirmed as correct, and a program group mapping relationship is generated; if they do not match, an alarm is triggered, and write operations on that program group are prohibited.

[0032] S3: Cache capture and mapping step. Start the programming software corresponding to the PLC project file, obtain the runtime cache data generated when the PLC project file is loaded by the programming software, establish a bidirectional mapping relationship between each member file in the member file list and the file with the same name in the cache data, and generate a cache comparison report.

[0033] In some embodiments, the cache acquisition process is as follows: Record the status of all existing session directories under the cache root directory of the programming software to form a baseline snapshot. Open the target project file through the system's default associated program, triggering the programming software to load the project file and write runtime cache data to the cache directory. Poll the cache root directory at 0.5-second intervals to identify session directories added after the baseline snapshot or whose latest modification time has changed. For the identified session directories, perform a steady-state determination based on their file count, cumulative byte count, and latest modification time. When these three items remain unchanged for 8 consecutive seconds and the total waiting time is not less than 10 seconds, it is determined that the cache writing of the session directory is complete, and the session directory has reached a steady state. Then, perform a second steady-state determination separately on the target project subdirectory in the session directory. When the file count, cumulative byte count, and latest modification time of the target project subdirectory remain unchanged for 8 consecutive seconds, it is determined that the cache writing of the target project subdirectory is complete, and the target project subdirectory has reached a steady state. This ensures that the session directory and subdirectories reach a bistable state, avoiding misjudgments caused by the programming software writing in batches. Subsequently, close the currently started programming software process and copy the session directory to the workspace as runtime cache data.

[0034] Then, using the database file `basename` (the filename including the hash prefix) as the association key, a two-way mapping relationship is established between the internal members of the project file and the files with the same name in the cache directory. That is, the project file points to the runtime cache, and the cache file traces back to the project file in a two-way same-origin binding. The system sets up a multi-layer fault tolerance mechanism, which does not force a one-to-one correspondence between the project and the cache file. It classifies and handles abnormal scenarios such as unique files on one side, files with the same name but different hashes, missing files in the same group, and naming deviations. It prioritizes ensuring the validity of the core business database mapping, restricts abnormal files to read-only and prohibits writing, while keeping the original project file structure unchanged. For each pair of files with the same name, the file size and SHA-256 hash value are calculated, and the fields such as `is_same_hash` (whether the bytes are completely identical) and the number of different bytes are output. Finally, a cache comparison report (cache_compare.json and cache_compare.csv) is generated.

[0035] This mapping allows for precise identification of which files were modified by the programming software when the project was opened. Real-world testing shows that the tag database and binary compilation artifacts are updated every time the project is opened, while core databases such as the ladder diagram database typically remain unchanged, making them safe as write targets.

[0036] S4: Structured report generation step. A structured report is generated based on the program group mapping relationship and the cache comparison report. The structured report includes a mandatory read order constraint, which is used to limit the order in which the large language model reads the data files in the structured report.

[0037] In some embodiments, the parsing software generates a structured report based on the program group mapping relationship and the cache comparison report. The structured report includes: workflow.json (the main entry contract, containing the absolute paths of all reports and read order constraint information), project_analysis.json (program group structure and database details), device_comments.csv (full device comments, UTF-8-BOM encoded), and project_report.md (human-readable summary).

[0038] The read order constraint specifies that the large language model must read each report in the following order: first, read `workflow.json` to obtain the absolute paths of all files; second, read `project_analysis.json` to understand the program group structure and database names; third, read `cache_compare.json` to understand which files were modified after being opened in the programming software; then, read `device_comments.csv` to obtain all device comments; and finally, read `project_report.md` as a human-readable summary to aid understanding. This order ensures that the large language model gradually delves into the specific details from the overall project overview, and only after obtaining the complete project context can it enter the modification plan generation stage, thereby reducing comprehension bias caused by missing context.

[0039] In some embodiments, the forced read order is implemented through the following program-level hard rules: A unique entry path binding restricts read requests from the large language model to only those initiated through a unified entry point, ensuring no read request can bypass system control and directly access the file system; a read state serial lock ensures multiple read requests are executed sequentially in a preset order, preventing concurrent reads from disrupting the preset order; a pre-order check verifies whether the structured report to be read by the current request conforms to the preset order before each read request is executed; if not, the request is rejected and an error is returned; and a read sequence log verifies the timestamp and report identifier of each read request for operation backtracking and auditing in case of anomalies. The forced read order is strictly controlled by the backend control system and does not rely on the large language model to autonomously comply.

[0040] S5: Large Language Model Decision Steps. The large language model reads each data file in the structured report according to the mandatory read order constraints, generates a modification plan based on the natural language modification intent, and performs a legality check on the modification plan.

[0041] In some embodiments, the user inputs natural language modification intent into the parsing software via command line. The parsing software submits the structured report to the large language model. The large language model reads the structured report sequentially according to the mandatory reading order specified in workflow.json, and infers and generates a structured modification plan in JSON format based on the user's modification intent. The plan explicitly specifies the target program group name, target database file, operation type (insert / update / upsert), target table name and field values, as well as all constraints that must be followed by the modification (blocktype whitelist, device address mapping rules, etc.).

[0042] Before outputting the modification plan, a validity check is performed, including: confirming whether the program block type of each write operation in the modification plan belongs to the allowed write type; if it does, the check passes; otherwise, the check fails. Confirming whether the filename of the target database file matches the program group structure record in the structured report; if they match, the check passes; otherwise, the check fails. Confirming whether the device address is within the valid range. The valid range includes the address range of soft components officially specified by the corresponding PLC model, distinguishing between X / Y octal address rules and M / D / T / C decimal address upper and lower limits, and combining this with the actual hardware allocation address recorded in the hardware configuration file; if it is within the valid range, the check passes; otherwise, the check fails. If any check fails, the modification plan is deemed invalid.

[0043] In some embodiments, the specific rules for the allowed write type of program blocks are as follows: Each record in the LadderBlocks table contains the fields id (identifier field), pos (position number field), blocktype (block type), and data (ladder type). Figure 2 (Number system data). This invention, through practical testing, establishes the following whitelist for the legality of block types: blocktype=0 (real ladder diagram block, including actual logic instructions such as LD, OUT, MOV) is allowed to be written; blocktype=5 (END termination block) is allowed to be written, and there is one and only one at the end of each program; blocktype=1 (line comment block) is prohibited from being written; blocktype=2 (header block) is prohibited from being written. blocktype=1 and 2 are automatically generated by the programming software during conversion and the binary index is updated synchronously; if the script is directly inserted, it will trigger the programming software to report a false error of "insufficient memory space", and the project file will not be able to be opened normally. The blocktype whitelist verification performs self-checks when the large language model is generated and modified, and eliminates illegal operations.

[0044] S6: Secure Direct Write and Verification Steps. Based on the modification plan that has passed the legality verification, a database direct write operation is performed on the PLC project file. This operation only writes to the database file, keeping the original bytes of the binary compilation artifacts and the hardware configuration file unchanged, and only allowing the writing of program blocks of the write-allowed type. This results in a modified database file. An integrity verification is then performed on the modified database file. If the verification passes, the modified database file is synchronously replaced back into the compressed container of the PLC project file according to the member mapping relationship in the cache comparison report. If the verification fails, the process is rolled back to the state before modification.

[0045] In some embodiments, all database write operations are strictly executed in the following mandatory order, and any failure in any step triggers a full rollback to the backup: Perform a full byte-level backup of the original project file, and simultaneously back up the entire cache directory. The backup is used to roll back to the pre-modification state if verification fails; extract a copy of the project file in a temporary working directory different from the backup directory, and perform a direct write operation on the target SQLite database on the copy. All writes are performed within a transaction, meaning multiple write operations within the same transaction are treated as a whole, either all successfully committed or all failing and rolled back; perform integrity verification on each modified SQLite database, and proceed to the next step only if all pass. If any database returns an exception, a full rollback is immediately triggered; according to the member mapping relationship in the cache comparison report, synchronously replace the modified database files in the temporary working directory back into the compressed container of the project file, keeping the original bytes of unaffected members completely unchanged to minimize modifications; repackage the modified file set into a new project file, ensuring the original project file is not overwritten throughout the process; reopen the new project file, trigger the programming software to perform compilation and conversion, read the conversion log, and determine that the patch is successful when Error: 0 and Warning: 0, and archiving is complete.

[0046] When writing device comments, the device comment database contains two related tables: DEVICE_DATA (stores device address records, with fields including SEQ, DevCode, ExtCode, ExtNo, DevNoHigh, and DevNoLow) and COMMENT_DATA (stores comment text, with fields including SEQ, DeviceSEQ, CmtNo, and CmtData). First, the device type letters (M, D, X, Y, etc.) are converted to DevCode encoding using a fixed mapping (M→1, D→32, X→16, Y→17, etc.). Then, the device number is split into high and low bytes (DevNoLow takes the lower 8 bits, DevNoHigh takes the higher 8 bits), while adapting to the octal address conversion rules for X / Y. Boundary cases include large device numbers (high 8 bits are non-zero), octal address parsing, zero-value addresses, and addresses exceeding the model limit. A combination of logic involving pre-address verification, radix conversion, and standard high / low byte splitting ensures complete compatibility between the written data and the storage rules of the programming software. The DEVICE_DATA table is checked to see if a record for the device already exists. If a match is found, its SEQ is read; otherwise, a new SEQ is assigned and a new row is inserted. Then, an upsert operation is performed in the COMMENT_DATA table with DeviceSEQ as the associated key and CmtNo=7 as the comment slot: if a corresponding comment already exists, the CmtData field is updated; otherwise, a new row is inserted. The entire process ensures atomicity through transactions, meaning that write operations to both tables are committed within the same transaction, and any failure in one table results in a complete rollback. This mechanism allows device comments to be retained or added in the modified project file, ensuring that the comment information in the new project file is consistent with the modification plan.

[0047] The selection of the fixed annotation slot CmtNo=7 strictly conforms to the dual-table association storage architecture of the built-in device annotation database in the programming software. It is only suitable for annotation editing work of the built-in DC device annotation database in the project and is applicable to PLC project files with private encapsulation formats. It can perform batch addition and modification operations of device annotations for various standard PLC device addresses such as X, Y, M, and D in the project. It is not suitable for editing non-device annotation scenarios such as ladder diagram program annotations, program block annotations, and label annotations.

[0048] The aforementioned secure write-through and verification mechanism is implemented through an atomic process of "backup—intra-transaction write—integrity verification—rollback". Before modification begins, the system performs a complete backup of the original project files and cache directory as a rollback baseline. During the write-through phase, all database write operations are executed within the same transaction, ensuring that multi-table writes are treated as a whole. If any write operation fails or integrity verification fails, the system automatically aborts the transaction and restores the project files and cache directory to their pre-modification state using the pre-saved backup. Through the collaborative mechanism of backup and transaction, write operations either succeed entirely, and the modified project files can be correctly recognized by the programming software, or they are all rolled back, and the original files are completely preserved, thus ensuring the security of the modification process and the integrity of the project files.

[0049] S7: Encapsulate the audit steps. Re-encapsulate the updated project file into a PLC project file and record the audit log.

[0050] In some embodiments, the audit log includes the file hash values ​​before and after modification, the modification timestamp, and the operator information. If there are still remaining modification requirements, the process can return to S5 to continue the next iteration without re-executing the parsing steps from S1 to S4.

[0051] In this embodiment, an actual industrial PLC engineering project was used as the test platform to verify the effectiveness of the above process. The updated project file passed the verification and compilation by programming software, proving that the present invention has practical value for engineering implementation.

[0052] See Figure 2 The present invention also provides a PLC project file parsing and safe direct writing editing system for large language models, comprising: The container parsing module is configured to decompress the target PLC project file as a compressed container, identify the member files within it, and obtain a list of member files. The program group pairing module is configured to pair multiple database files belonging to the same program group based on the program group identifier in the file name of each database file, thereby generating a program group mapping relationship. The cache capture and mapping module is configured to launch the programming software corresponding to the PLC project file, obtain the runtime cache data generated when the PLC project file is loaded by the programming software, establish a bidirectional mapping relationship between each member file in the member file list and the file with the same name in the cache data, and generate a cache comparison report. The structured report generation module is configured to generate a structured report based on the program group mapping relationship and the cache comparison report. The structured report includes a mandatory read order constraint, which is used to limit the order in which the large language model reads each data file in the structured report. The large language model decision module is configured to have the large language model read each data file in the structured report according to the mandatory reading order constraint, generate a structured modification plan based on the natural language modification intent, and perform a legality check on the structured modification plan; The secure direct write and verification module is configured to perform a database direct write operation on the PLC project file according to the structured modification plan that has passed the legality verification. The database direct write operation only performs writing on the database file, keeping the original bytes of the binary compilation product and the hardware configuration file unchanged, and only allowing the writing of program blocks of the write-allowed type to obtain the modified database file. The module then performs an integrity verification on the modified database file. If the verification passes, the modified database file is synchronously replaced back into the compressed container of the PLC project file according to the member mapping relationship in the cache comparison report. If the verification fails, the system rolls back to the state before modification. The encapsulation and auditing module is configured to re-encapsulate the updated project files into PLC project files and record audit logs.

[0053] Example 2: Ladder diagram cloning and device number remapping In one embodiment, for scenarios requiring the addition of verified logic blocks (such as TCPSocket communication libraries) to the project file, the present invention employs a row-level cloning and device number remapping method: First, from the ladder diagram database and variable database of the source program, ladder diagram block data with blocktype=0 is read row by row using the position number field as an index, and cloned into the corresponding database copy of the target program; then, according to the predefined device address mapping table (format: {position number field: (old device number, new device number)}), the device number bytes in the cloned data are precisely replaced (e.g., M1000→M3000, D2000→D8200); simultaneously, deterministic text replacement is performed on the mnemonic strings in the variable database (e.g., SP.SOCOPEN→SP_SOCOPEN, MOVP→MOV) to adapt to the instruction format of the target program; finally, the block index table, step index table, and source position mapping table in the step information database are rebuilt to complete the synchronous update of the program step index, ensuring that the cloned new ladder diagram program can be correctly recognized and compiled by the programming software.

[0054] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. For those skilled in the art, the present invention can have various modifications and variations. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention. In the above embodiments provided by the present invention, it should be understood that the disclosed systems, devices, and methods can be implemented in other ways. For example, the device 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.

[0055] In summary, although the present invention has been disclosed above with reference to preferred embodiments, the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the concept of the technical solution of the present invention, should be covered within the scope of protection of the present invention.

Claims

1. A method for parsing and safely writing PLC project files for large language models, characterized in that, Includes the following steps: S1: Decompress the target PLC project file as a compressed container, identify the member files, and obtain a list of member files; the member files include database files, binary compilation artifacts, and hardware configuration files; S2: Based on the program group identifier in the filename of each of the database files, pair up multiple database files belonging to the same program group to generate a program group mapping relationship; S3: Start the programming software corresponding to the PLC project file, obtain the runtime cache data generated when the PLC project file is loaded by the programming software, establish a bidirectional mapping relationship between each member file in the member file list and the file with the same name in the cache data, and generate a cache comparison report; S4: Generate a structured report based on the program group mapping relationship and the cache comparison report. The structured report includes a mandatory read order constraint, which is used to limit the order in which the large language model reads each data file in the structured report. S5: The large language model reads each data file in the structured report according to the mandatory reading order constraint, generates a modification plan based on the natural language modification intent, and performs a legality verification on the modification plan; S6: According to the modification plan that has passed the legality check, perform a database direct write operation on the PLC project file. The database direct write operation only writes to the database file, keeping the original bytes of the binary compilation product and the hardware configuration file unchanged, and only allowing the writing of program blocks of the write-allowed type to obtain the modified database file. Perform an integrity check on the modified database file. If the check passes, the modified database file is synchronously replaced back into the compressed container of the PLC project file according to the member mapping relationship in the cache comparison report. If the check fails, roll back to the state before modification. S7: Repackage the updated project file into a PLC project file and record the audit log.

2. The method according to claim 1, characterized in that, The step of pairing multiple database files belonging to the same program group based on the program group identifier in the filename of each database file to generate a program group mapping relationship includes: The database file includes a ladder diagram database, a variable database, and a step information database; The program group identifier is the hash prefix in the filename of the database file; Using the hash prefix in the filename of each database file as the association key, the ladder diagram database, the variable database, and the step information database under the same hash prefix are grouped into a program group; The total number of ladder diagram physical blocks in the ladder diagram database is compared with the total number of registered blocks in the step information database to verify whether the merging is correct; wherein, the total number of ladder diagram physical blocks is the number of program logic blocks actually stored in the ladder diagram database, the total number of registered blocks is the number of step indexes recorded in the step information database, and the total number of ladder diagram physical blocks from the same program group and the total number of registered blocks should be consistent; When the total number of physical blocks in the ladder diagram is consistent with the total number of registered blocks, the merging is confirmed to be correct, and the program group mapping relationship is generated; when the total number of physical blocks in the ladder diagram is inconsistent with the total number of registered blocks, an alarm is triggered and the program group is prohibited from performing write operations.

3. The method according to claim 1, characterized in that, The step of obtaining runtime cache data generated when the PLC project file is loaded by the programming software includes: S3.1: Record the status of all existing session directories under the cache root directory of the programming software to form a baseline snapshot; S3.2: Open the PLC project file through the system's default associated program, triggering the programming software to load the PLC project file and write runtime cache data to the programming software's cache directory; S3.3: Poll the cache root directory at 0.5-second intervals to identify session directories that have been added or whose latest modification time has changed since the baseline snapshot; S3.4: For the identified session directory, a steady-state determination is made based on its number of files, cumulative number of bytes, and latest modification time. When the number of files, cumulative number of bytes, and latest modification time remain unchanged for 8 consecutive seconds and the total waiting time is not less than 10 seconds, it is determined that the cache writing of the session directory is completed and the session directory has reached a steady state. S3.5: Perform a second steady-state determination on the target project subdirectory in the session directory. When the number of files, the cumulative number of bytes, and the latest modification time of the target project subdirectory remain unchanged for 8 consecutive seconds, it is determined that the cache writing of the target project subdirectory is complete and the target project subdirectory has reached a steady state. S3.6: Close the programming software process that was started this time; S3.7: Copy the session directory to the workspace as runtime cache data.

4. The method according to claim 1, characterized in that, The mandatory read order constraint is implemented in the following way: By binding a unique entry path, the read requests for the large language model are limited to being initiated only through a unified entry point; By reading the status serial lock, multiple read requests can be executed in a preset order; By performing a pre-order check, the structured report to be read in the current request is checked before each read request is executed to see if it conforms to the structured report that should be read in the preset order; Verification is performed by reading the time-series log, recording the timestamp of the read request and the report identifier.

5. The method according to claim 1, characterized in that, The legality verification of the modification plan includes: Perform an allowable type check on the program block type of each write operation in the modification plan to confirm whether the program block type of each write operation in the modification plan belongs to the allowable write type program block. If it belongs, the check passes; otherwise, the check fails. Confirm whether the filename of the target database file in the modification plan is consistent with the program group structure record in the structured report. If they are consistent, the verification passes; if they are inconsistent, the verification fails. Verify whether the device address in the modification plan is within the valid range. The valid range includes the address range of the soft components officially specified by the PLC for the corresponding model in the PLC project file and the actual hardware allocation address of the local machine recorded in the hardware configuration file. If it is within the valid range, the verification passes; if it exceeds the range, the verification fails.

6. The method according to claim 5, characterized in that, The program blocks that are allowed to be written include real ladder diagram blocks with blocktype=0 and END termination blocks with blocktype=5; blocks that are prohibited from being written include line comment blocks with blocktype=1 and header blocks with blocktype=2. The END termination block allows for position updates of existing END termination blocks, or the addition of a missing END termination block, but prohibits the creation of multiple new END termination blocks.

7. The method according to claim 1, characterized in that, The process of performing an integrity check on the modified database file includes: Perform a PRAGMA integrity_check on each modified database file to verify the integrity of the internal structure of the database file; The verification is considered successful when all database files return "ok". When any database file returns an exception, a full rollback to the state before modification is triggered.

8. A PLC project file parsing and safe direct-write editing system for large language models, characterized in that, include: The container parsing module is configured to decompress the target PLC project file as a compressed container, identify the member files within it, and obtain a list of member files; the member files include database files, binary compilation artifacts, and hardware configuration files. The program group pairing module is configured to pair multiple database files belonging to the same program group based on the program group identifier in the file name of each database file, thereby generating a program group mapping relationship. The cache capture and mapping module is configured to launch the programming software corresponding to the PLC project file, obtain the runtime cache data generated when the PLC project file is loaded by the programming software, establish a bidirectional mapping relationship between each member file in the member file list and the file with the same name in the cache data, and generate a cache comparison report. The structured report generation module is configured to generate a structured report based on the program group mapping relationship and the cache comparison report. The structured report includes a mandatory read order constraint, which is used to limit the order in which the large language model reads each data file in the structured report. The large language model decision module is configured to have the large language model read each data file in the structured report according to the mandatory reading order constraint, generate a structured modification plan based on the natural language modification intent, and perform a legality check on the structured modification plan; The secure direct write and verification module is configured to perform a database direct write operation on the PLC project file according to the structured modification plan that has passed the legality verification. The database direct write operation only performs writing on the database file, keeping the original bytes of the binary compilation product and the hardware configuration file unchanged, and only allowing the writing of program blocks of the write-allowed type to obtain the modified database file. The module then performs an integrity verification on the modified database file. If the verification passes, the modified database file is synchronously replaced back into the compressed container of the PLC project file according to the member mapping relationship in the cache comparison report. If the verification fails, the system rolls back to the state before modification. The encapsulation and auditing module is configured to re-encapsulate the updated project files into PLC project files and record audit logs.

9. The system according to claim 8, characterized in that, When the secure direct write and verification module performs a database direct write operation, it only allows writing of real ladder diagram blocks with a blocktype value of 0 and END termination blocks with a blocktype value of 5, and refuses to write of line comment blocks with a blocktype value of 1 and header blocks with a blocktype value of 2. The END termination block allows for position updates of existing END termination blocks, or the addition of a missing END termination block, but prohibits the creation of multiple new END termination blocks.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 7.

Images