A method for compiling and running configuration of embedded configuration software based on DSL semantic mapping

Abstract

The application relates to a kind of embedded configuration software compiling and running configuration method based on DSL semantic mapping, comprising: step S1 reads the project running configuration containing script, mapping, collector, variable, hardware binding and other information;S2 relies on DSL fragment library to generate fragment insertion record containing identification, code and the like;S3 generates semantic mapping entry from record and enters configuration;S4 checks the consistency of field, channel, identification, signal, period, variable, hardware resource and the like before compiling;S5 standardizes DSL syntax, unifies call and parameter format, completes program structure;S6 compiles standardized file and records product information;S7 generates running task configuration by associating the configuration after checking and compiling product;S8 executes task according to priority, period and scheduling mode in runtime.Compared with the prior art, the application has the advantages of solving the problems such as disconnection between DSL fragment and running object in existing system and poor compatibility of old script.

Description

Technical Field

[0001] This invention relates to the fields of embedded real-time control systems, industrial configuration software, domain-specific language (DSL) compilation, runtime scheduling, communication protocol identification, and real-time monitoring data processing, and in particular to a method for compiling and configuring embedded configuration software based on DSL semantic mapping. Background Technology

[0002] Existing embedded configuration software typically employs source code modification and complete recompilation to update functions, adjust parameters, and deploy operations. This approach suffers from low functional reusability, a wide scope of system upgrades, and a lack of unified mapping between configuration items and operational logic. For industrial control scenarios characterized by multi-device access, multi-channel monitoring, and multi-parameter configuration, users often need to maintain different data structures and configuration files during the design, compilation, download, and operation phases, making it difficult to establish a unified closed-loop management system among engineering objects, operational objects, and communication objects.

[0003] Existing solutions often manage DSL segments, communication channels, parameter definitions, and hardware resources in a decentralized manner, lacking a description of the assembly relationship oriented towards functional blocks. This results in a lack of consistency constraints between project saving, compilation, deployment, and runtime scheduling, easily leading to duplicate bindings, resource conflicts, incorrect channel mapping, or runtime adaptation errors. For older scripts or historical project files, existing compilation processes have limited syntax compatibility, entry point completion capabilities, and compilation artifact tracing capabilities. They typically require manual script structure adjustments before compilation can be completed, increasing migration and maintenance costs.

[0004] Furthermore, in communication access and real-time monitoring scenarios, existing systems often rely on manual selection of protocol types, manual switching of download interfaces, and full refresh of monitoring data display. This fails to establish an automatic linkage between protocol identification, download switching, data acquisition, incremental consumption, and interface refresh. When the number of channels increases, the sampling frequency rises, or data fluctuations are significant, the system is prone to problems such as slow configuration switching, excessive refresh overhead, and display lag, further impacting overall delivery stability and operational efficiency. Summary of the Invention

[0005] The purpose of this invention is to provide a method for compiling and configuring embedded configuration software. By unifying DSL segments, project configuration, compilation artifacts, running tasks, communication protocols, and monitoring data processing into a structured semantic mapping link, this method solves the problems in existing systems such as the disconnect between DSL segments and running objects, poor compatibility with old scripts, untraceable compilation artifacts, difficulty in timely detection of configuration conflicts, lack of anomaly protection in running scheduling, and excessive overhead in high-frequency monitoring data processing.

[0006] The objective of this invention can be achieved through the following technical solutions: A method for compiling and configuring embedded configuration software based on DSL semantic mapping, comprising the following steps: S1, Read the project runtime configuration, which includes the DSL main script path, script file list, DSL semantic mapping list, monitoring collector provider list, variable definition list, parameter definition list, hardware resource binding list, and download artifact configuration; S2, Generate DSL segment insertion records based on the DSL segment library. The DSL segment insertion records include a unique segment identifier, segment name, mapping identifier, insertion row number, generation code, and insertion time. S3, Generate a DSL semantic mapping entry based on the DSL segment insertion record, and write the DSL semantic mapping entry into the project runtime configuration. The DSL semantic mapping entry includes a unique mapping identifier, segment identifier, channel name, signal path, physical unit, sampling period, script line number, generation code, and metadata. S4. Before compilation, perform consistency checks on the runtime configuration of the project. The consistency checks include checks on required fields of the project, duplicate checks on monitoring channels, duplicate checks on mapping identifiers, duplicate checks on signal path bindings, checks on sampling period range, checks on the integrity of variable definitions, checks on the integrity of parameter definitions, and checks on the upper limit of the number of hardware resources. S5, Perform syntax normalization processing on the DSL source file. The syntax normalization processing includes converting the instance assignment call form in the old DSL into a unified call form, converting the equal sign assignment in the function block call parameters into a standardized parameter binding form, and automatically completing the program entry point, variable declaration section and program end section when the program wrapping structure is missing. S6, call the DSL compiler to compile the normalized DSL source file input, generate compilation products, and record the product type, output path, output format, check value, source file path, main script path and script file list for the compilation products; S7. Generate a runtime task configuration based on the project runtime configuration that has passed the consistency check, and associate the runtime task configuration with the download product record of the compilation product; S8, during the running phase, based on the running task configuration, the running task is executed according to the task priority, sampling period and scheduling mode.

[0007] Furthermore, the DSL segments in the DSL segment library include a unique segment identifier, a segment display name, a segment category, a segment description, a DSL template code, a default unit, a default sampling period, and additional metadata; the additional metadata includes at least a function block type identifier and a compiler name; The DSL segment also includes at least one of memory usage and number of parameters.

[0008] Furthermore, the DSL semantic mapping entry uses a UUID as a unique mapping identifier and is saved via JSON serialization. When the project is reopened, the system restores the correspondence between the DSL semantic mapping entry and the DSL segment based on the unique mapping identifier and at least one of the script line number and the inserted record.

[0009] Furthermore, the syntax normalization process includes: extracting instance names and function block types by matching the "instance name = function block type" format in the old DSL source file using regular expressions; generating an instance declaration list according to the order in which instance names appear; writing the instance names and function block types into an instance type mapping table; converting instance assignment call statements in the old DSL source file into unified call statements with instance names as the calling objects; and converting the assignment symbol "=" between the parameter name and parameter value to ":=" when the bracket depth is greater than zero, the current line matches a single parameter assignment statement "parameter name = parameter value", and does not contain ":=" or "=>".

[0010] Furthermore, when the standardized DSL source file is missing PROGRAM and END_PROGRAM, the program name is generated based on the source file name, and the PROGRAM line, VAR line, variable declaration formed by the instance declaration list, END_VAR line, and END_PROGRAM line are automatically completed.

[0011] Furthermore, the running task configuration includes task name, priority, execution cycle, execution function or execution function reference, scheduling mode, task status, last execution time, next planned execution time, alarm threshold, maximum number of consecutive errors, and enable flag; wherein, when registering a task, the priority is limited to a preset range, the execution cycle is limited to not less than 1ms, and tasks are arranged in ascending order of priority.

[0012] Furthermore, the scheduling mode includes a fixed delay scheduling mode and a fixed frequency scheduling mode; in the fixed delay scheduling mode, the difference between the current time and the last execution completion time is used to determine whether the running task has expired; in the fixed frequency scheduling mode, the next planned execution time is used to determine whether the running task has expired, and the next planned execution time is resynchronized when the task execution is behind schedule.

[0013] Furthermore, during the operation phase, monitoring data is acquired, and the monitoring data processing during the operation phase includes: creating a fixed-capacity circular buffer and an incremental buffer for each monitoring channel; when a sampling point arrives, the sampling point is written to the circular buffer, and when incremental mode is enabled, it is written to the incremental buffer; when the number of data in the incremental buffer reaches the batch processing threshold, an incremental data ready event is triggered; during the consumption phase, the incremental buffer is retrieved and cleared; and the point sequence in the circular buffer is sequentially subjected to time window pruning, amplitude limiting, smoothing, fixed factor downsampling, adaptive downsampling, and display point limit.

[0014] Furthermore, the circular buffer is a fixed-capacity buffer structure; when adding sampling points, if the buffer is not full, the sampling point is written to a new position determined by the head position and the current number of elements; if the buffer is full, a new sampling point is written and the head position is moved to discard the oldest sampling point.

[0015] Furthermore, the method also includes a protocol identification step, which includes: performing passive protocol identification based on the frame structure, length field, function code, protocol identifier field, check field, or identifier field of the frame received by the communication interface; when the confidence level of the passive protocol identification is lower than a preset threshold, and the communication interface is in an allowed probe state or within a security detection window, sending a candidate protocol probe frame to the communication interface; performing at least one of CRC16 check, MBAP header check, COB-ID range check, J1939 priority, and PGN feature parsing on the response frame; generating a confidence level for each candidate protocol, and selecting the protocol with the highest confidence level that reaches the identification threshold as the identification result to determine the corresponding communication protocol type.

[0016] Furthermore, the compilation output is a compilation output file with the suffix .code generated based on the basic name of the DSL source file, and the verification value is the SHA-256 verification value of the .code file; the metadata of the compilation output at least records the source file path, main script path, script file list, output scope and output directory.

[0017] Compared with the prior art, the present invention has the following beneficial effects: By binding DSL segments with channel names, signal paths, units, sampling periods, script line numbers, and metadata, a storable, recoverable, and traceable semantic mapping link is formed. Simultaneously, automatic standardization of old DSL syntax and program wrapping completion reduce the manual modification costs of migrating historical project scripts to a unified compilation process; recording output paths, formats, SHA-256 checksums, and source script information for compilation artifacts improves artifact traceability during downloading, debugging, and version rollback; pre-compilation consistency checks proactively identify duplicate channels, duplicate mappings, resource overruns, and invalid sampling periods, reducing runtime configuration conflicts; fixed-delay and fixed-frequency scheduling modes, along with timeout alarms and continuous error disabling mechanisms, improve the stability and anomaly isolation capabilities of runtime task scheduling; fixed-capacity circular buffers, incremental consumption, and adaptive downsampling keep the memory usage of historical monitoring data under control and reduce the overhead of full refresh in high-frequency sampling scenarios; and automatic identification and channel switching in multi-protocol communication environments are achieved through protocol probe frame and response frame feature analysis and confidence selection. Attached Figure Description

[0018] Figure 1 This is a schematic diagram illustrating the overall compilation, configuration, and execution process of this invention; Figure 2 This is a schematic diagram of the semantic mapping entries and semantic assembly unit structure of DSL; Figure 3 This is a diagram illustrating the DSL syntax standardization and compilation process. Figure 4 This is a schematic diagram of the consistency verification and operation scheduling process; Figure 5 A schematic diagram illustrating the encapsulation of compilation outputs and the recording of results; Figure 6 This is a schematic diagram of the incremental processing flow for protocol identification and monitoring. Detailed Implementation

[0019] The present invention will now be described in detail with reference to the accompanying drawings and specific embodiments. These embodiments are based on the technical solution of the present invention and provide detailed implementation methods and specific operating procedures. However, the scope of protection of the present invention is not limited to the following embodiments.

[0020] This invention proposes a method for compiling and configuring embedded configuration software based on DSL semantic mapping, comprising the following steps: S1, Read the project runtime configuration, which includes the DSL main script path, script file list, DSL semantic mapping list, monitoring collector provider list, variable definition list, parameter definition list, hardware resource binding list, and download artifact configuration; S2, Generate DSL segment insertion records based on the DSL segment library. The DSL segment insertion records include a unique segment identifier, segment name, mapping identifier, insertion row number, generation code, and insertion time. S3, Generate a DSL semantic mapping entry based on the DSL segment insertion record, and write the DSL semantic mapping entry into the project runtime configuration. The DSL semantic mapping entry includes a unique mapping identifier, segment identifier, channel name, signal path, physical unit, sampling period, script line number, generation code, and metadata. S4. Before compilation, perform consistency checks on the runtime configuration of the project. The consistency checks include checks on required fields of the project, duplicate checks on monitoring channels, duplicate checks on mapping identifiers, duplicate checks on signal path bindings, checks on sampling period range, checks on the integrity of variable definitions, checks on the integrity of parameter definitions, and checks on the upper limit of the number of hardware resources. S5, Perform syntax normalization processing on the DSL source file. The syntax normalization processing includes converting the instance assignment call form in the old DSL into a unified call form, converting the equal sign assignment in the function block call parameters into a standardized parameter binding form, and automatically completing the program entry point, variable declaration section and program end section when the program wrapping structure is missing. S6, call the DSL compiler to compile the normalized DSL source file input, generate compilation products, and record the product type, output path, output format, check value, source file path, main script path and script file list for the compilation products; S7. Generate a runtime task configuration based on the project runtime configuration that has passed the consistency check, and associate the runtime task configuration with the download product record of the compilation product, wherein the download product record of the compilation product is used as the basis for downloading or redeploying to the target device. S8, during the running phase, based on the running task configuration, the running task is executed according to the task priority, sampling period and scheduling mode.

[0021] The DSL segments in the DSL segment library include a unique segment identifier, segment display name, segment category, segment description, DSL template code, default unit, default sampling period, and additional metadata; the additional metadata includes at least a function block type identifier and a compiler name, and further includes at least one of memory usage and the number of parameters.

[0022] The DSL fragment insertion record is generated by the DSL editor when inserting fragments by dragging and dropping or by code completion; the system establishes an association between the DSL semantic mapping entries in the project configuration file and the code locations in the DSL script based on the mapping identifier.

[0023] The DSL semantic mapping entries are uniquely identified by UUID and saved via JSON serialization. When the project is reopened, the system restores the correspondence between the DSL semantic mapping entries and DSL code snippets based on the unique mapping identifier and at least one of script line number, inserted record, or script tag.

[0024] The syntax normalization process includes: extracting instance names and function block types by matching the "instance name = function block type" format in the old DSL source file using regular expressions; generating an instance declaration list according to the order in which instance names appear; writing the instance names and function block types into an instance type mapping table; converting instance assignment call statements in the old DSL source file into unified call statements with instance names as the calling objects; and converting the assignment symbol "=" between the parameter name and parameter value to ":=" when the bracket depth is greater than zero, the current line matches a single parameter assignment statement "parameter name = parameter value", and does not contain ":=" or "=>".

[0025] When the normalized DSL text is missing PROGRAM and END_PROGRAM, the program name is generated based on the source file name, and the PROGRAM line, VAR line, variable declaration formed by the instance declaration list, END_VAR line, and END_PROGRAM line are automatically completed.

[0026] The compilation output is a compilation output file with the suffix .code generated based on the basic name of the DSL source file. The verification value is the SHA-256 verification value of the .code file. The metadata of the compilation output records at least the source file path, main script path, script file list, output scope, and output directory.

[0027] The consistency verification also includes: integrity verification of the ID, name and data type of variable definition; integrity verification of the ID, name and data type of parameter definition; integrity verification of the resource type and channel bound to hardware resources; verification of duplicate occupation of the same resource type and the same channel combination; and verification of whether the number of AI / AO analog resources, the number of DI / DO digital resources and the number of monitoring channels exceed the corresponding preset upper limit.

[0028] The running task configuration includes task name, priority, execution cycle, execution function or execution function reference, scheduling mode, task status, last execution time, next planned execution time, alarm threshold, maximum number of consecutive errors, and enable flag; wherein, when registering a task, the priority is limited to a preset range, the execution cycle is limited to not less than 1ms, and tasks are arranged in ascending order of priority.

[0029] The scheduling modes include a fixed delay scheduling mode and a fixed frequency scheduling mode. In the fixed delay scheduling mode, the difference between the current time and the last execution completion time is used to determine whether the running task has expired. In the fixed frequency scheduling mode, the next planned execution time is used to determine whether the running task has expired, and the next planned execution time is resynchronized when the task execution is behind schedule.

[0030] During the runtime phase, the execution time, number of executions, number of errors, and number of consecutive errors of the running task are statistically analyzed; when the execution time exceeds the alarm threshold, a timeout alarm is issued; when the number of consecutive errors reaches the maximum number of consecutive errors, the corresponding running task is disabled.

[0031] The monitoring data processing during the operation phase includes: creating a fixed-capacity circular buffer and an incremental buffer for each monitoring channel; writing the sampling point to the circular buffer when it arrives, and writing it to the incremental buffer when incremental mode is enabled; triggering an incremental data ready event when the number of data in the incremental buffer reaches the batch processing threshold; retrieving and clearing the incremental buffer during the consumption phase; and sequentially performing time window clipping, amplitude limiting, smoothing, fixed factor downsampling, adaptive downsampling, and display point limit on the point sequence in the circular buffer.

[0032] The circular buffer is a fixed-capacity buffer structure. When adding sampling points, if the buffer is not full, the sampling point is written to a new position determined by the head position and the current number of elements. If the buffer is full, the new sampling point is written and the head position is moved to eliminate the oldest sampling point, so that the memory usage of the sampling history cache remains fixed.

[0033] The protocol identification step also includes: performing passive protocol identification based on the frame structure, length field, function code, protocol identifier field, check field, or identifier field of the received frame from the communication interface; when the confidence level of the passive protocol identification is lower than a preset threshold, and the communication interface is in an allowed probe state or within a security detection window, sending a candidate protocol probe frame to the communication interface; the candidate protocol probe frame includes probe frames corresponding to at least one of ModbusRTU, ModbusTCP, CANopen, J1939, and RawCAN; performing at least one of CRC16 check, MBAP header check, COB-ID range check, J1939 priority, and PGN feature parsing on the response frame; generating a confidence level for each candidate protocol, and selecting the protocol with the highest confidence level that reaches the identification threshold as the identification result to determine the corresponding communication protocol type.

[0034] This invention also proposes an embedded configuration software system, comprising: a project configuration management module for maintaining project runtime configuration, the project runtime configuration including DSL main script path, script file list, DSL semantic mapping list, monitoring collector provider list, variable definition list, parameter definition list, hardware resource binding list, and download artifact configuration; a fragment library module for maintaining DSL fragments containing DSL template code, default unit, default sampling period, and metadata; a semantic mapping module for generating DSL semantic mapping entries based on DSL fragment insertion records and writing the DSL semantic mapping entries into the project runtime configuration; and a consistency verification module for... Before compilation, the system performs verification of required fields, monitoring channels, mapping identifiers, signal paths, sampling periods, variable definitions, parameter definitions, and hardware resources. A compilation normalization module performs old syntax conversion and program wrapping completion on the DSL source files. A compilation execution module calls the DSL compiler to generate compilation artifacts and records artifact verification values ​​and metadata. A runtime scheduling module generates runtime task configurations based on the project runtime configurations that pass consistency verification and schedules runtime tasks according to these configurations. The runtime task configurations are associated with the download artifact records of the compilation artifacts, which serve as the basis for downloading or redeploying to the target device.

[0035] The operation scheduling module includes a task table, a task statistics table, and a timed tick trigger; the tasks in the task table are arranged in ascending order of priority, and the timed tick trigger determines the due tasks based on a fixed delay scheduling mode or a fixed frequency scheduling mode.

[0036] The monitoring data processing module includes a channel buffer table, a circular buffer, an incremental buffer, a processing result cache, and a performance statistics unit, which are used to perform fixed-capacity caching, incremental consumption, time window pruning, smoothing, downsampling, and adaptive downsampling on the sampling points.

[0037] The protocol identification module includes a passive identification unit, a candidate protocol detection unit, a response frame analysis unit, and a confidence level selection unit. The passive identification unit generates an initial protocol confidence level based on the characteristics of the received frame. The candidate protocol detection unit sends a candidate protocol detection frame when the initial protocol confidence level is lower than a preset threshold and the communication interface is in a probe-allowed state or within a security detection window. The response frame analysis unit performs at least one of the following: Modbus RTU CRC16 check, Modbus TCP MBAP header check, CANopen COB-ID check, and J1939 priority and PGN feature parsing. The confidence level selection unit selects the protocol with the highest confidence level that reaches the identification threshold as the identification result.

[0038] First, the project runtime configuration is read. The project runtime configuration includes the DSL main script path, script file list, DSL semantic mapping list, monitoring collector provider list, variable definition list, parameter definition list, hardware resource binding list, and download artifact configuration.

[0039] The system maintains a DSL segment library. Each DSL segment contains a unique segment identifier, segment display name, segment category, segment description, DSL template code, default unit, default sampling period, and additional metadata. When a user inserts a DSL segment via drag-and-drop or code completion, the system generates a DSL segment insertion record and generates a DSL semantic mapping entry based on the insertion record.

[0040] The system performs syntax normalization on the DSL source files, including at least old instance assignment call form conversion, parameter assignment symbol conversion, and program wrapping structure completion. The normalized DSL input is passed to the DSL compiler for compilation. After compilation, compilation artifacts such as .code are generated, and the system records the artifact type, output path, output format, checksum, source file path, main script path, and script file list for each artifact.

[0041] Before compilation, the system performs a consistency check, which includes required fields, duplicate channels, duplicate mapping identifiers, duplicate signal paths, sampling period ranges, variable definitions, parameter definitions, and the maximum number of AI / AO / DI / DO hardware resources. Only DSL semantic mapping entries and compilation artifacts that pass the check will be associated with running tasks.

[0042] During the runtime phase, the system executes tasks based on task priority, sampling period, and scheduling mode. Scheduling modes include fixed-delay scheduling and fixed-frequency scheduling. The system tracks the number of executions, execution time, number of errors, and number of consecutive errors for each task, and triggers alarms or disables the task when it times out or the number of consecutive errors reaches a threshold.

[0043] For real-time monitoring data, the system creates a fixed-capacity circular buffer and an incremental buffer for each channel. Upon arrival of a sampling point, data is simultaneously written to both the circular and incremental buffers. A consumption event is triggered when the incremental data reaches the batch processing threshold. During the consumption phase, time window pruning, amplitude limiting, smoothing, downsampling, adaptive downsampling, and display point limitation are applied to the data, thereby reducing the overhead of a full refresh.

[0044] For multi-protocol access scenarios, the system sends candidate protocol probe frames to the communication interface, performs protocol feature analysis such as CRC, MBAP, COB-ID, and PGN on the response frames, forms the confidence level of the candidate protocols, and selects the protocol with the highest confidence level to switch the corresponding communication channel or download channel.

[0045] The specific steps of this invention are as follows: Step S1: Project runtime configuration like Figure 1 As shown, the system maintains the project runtime configuration when a project is created, opened, or saved. This project runtime configuration is used to transfer the same set of structured data between the design, compilation, download, and runtime phases.

[0046] Table 1 Fields in S1 Step S2: Fragment Library and Fragment Insertion Record like Figure 2 As shown, the system maintains a configurable DSL fragment library. Each fragment includes at least id, name, category, description, templateCode, unit, defaultPeriodMs, and metadata. Metadata may contain compilation or runtime related information such as typeId, memorySize, parameterCount, and compilerName.

[0047] When a user drags and drops a snippet from the snippet library into the DSL editor, or inserts a snippet via code completion, the system generates a DSL snippet insertion record. This record includes snippetId, snippetName, mappingId, lineNumber, generatedCode, and insertTime. The mappingId is used to associate the position in the script text with a semantic mapping entry in the project configuration.

[0048] For example, a fragment library can contain the following DSL template code: comm_can_init_1=_CommCANInit(); comm_j1939_trans_1=_CommJ1939Trans(); comm_watch_1 = _CommWatch(); Step S3: DSL semantic mapping entries DSL semantic mapping entries are used to describe the binding relationship between DSL fragments and runtime objects. Each mapping is uniquely identified by a UUID and stored in JSON format.

[0049] Table 2 Fields in S2 When the project reopens, the system first scans the mapping tags in the script and establishes a mapping from mappingId to script line number; then it aligns the DSL semantic mapping entries in the project configuration with the script text tags. If a tag exists in the script but the corresponding mapping does not exist in the configuration, the system can restore the minimum mapping entry based on the DSL call format of the tag line.

[0050] Step S4: DSL Syntax Normalization Processing like Figure 3 As shown, the system performs syntax normalization on the DSL source file before invoking the compiler. This process includes old instance assignment call conversion, parameter assignment symbol conversion, and program wrapping structure completion.

[0051] In one embodiment, the system uses regular expressions to match the "instance name = function block type()" format in the old DSL syntax. Upon successful matching, the system extracts the instance name and function block type, writes the instance name into the instance declaration list, writes the instance name and function block type into the instance type mapping table, and converts the row into the "instance name()" format.

[0052] When processing a parameter line inside the parentheses of a function block call, if the line does not contain ":=" or "=>" and matches the form "parameter name=parameter value", the system converts the "=" to ":=".

[0053] Examples of the conversion are shown in Table 3: Table 3 Conversion Examples If the converted DSL text does not detect PROGRAM and END_PROGRAM, the system generates the program name based on the source file's base name and automatically completes PROGRAM, VAR, instance declaration, END_VAR, and END_PROGRAM. Through this process, old project scripts can be converted into standardized input that can be processed by the unified DSL compiler.

[0054] Step S5: Compilation, Execution, and Product Packaging like Figure 5 As shown, the system calls the DSL compiler through the compilation execution module. The compiler entry point can be the lmc.py script located in the preset working directory. Before the call, the system checks whether the Python interpreter and the DSL compiler runtime dependencies are available to avoid entering an unrecoverable compilation process when the runtime environment is missing.

[0055] The compiled output file is preferably generated based on the base name of the DSL source file and uses the .code suffix. After compilation, the system calculates the SHA-256 checksum of the output file and generates a compilation artifact record, as shown in Table 4.

[0056] Table 4 Compilation artifact records By using the above-mentioned artifact encapsulation method, subsequent download, version replacement, debugging, and rollback processes can be verified based on the same artifact record, reducing deployment risks caused by inconsistencies between downloaded files and source scripts.

[0057] Step S6: Consistency Verification like Figure 4 As shown, the system performs a consistency check before compilation. If the check fails, the system returns the conflict object, conflict type, and correction suggestion, and then aborts the compilation. The check items are shown in Table 5.

[0058] Table 5 Verification Items Step S7: Run Task Scheduling The system associates DSL semantic mapping entries with compilation artifacts through consistency checks as running tasks. Each running task includes a task name, priority, period, execution function, scheduling mode, task status, last execution time, next scheduled execution time, alarm threshold, maximum number of consecutive errors, and enable flag.

[0059] During task registration, the system performs boundary processing on priority and period. Priority is limited to a preset range, and period is limited to no less than 1ms. After registration, the system arranges tasks in ascending order of priority, ensuring that higher-priority tasks are executed first within the same tick.

[0060] In fixed-delay scheduling mode, the system uses the task's last execution completion time as a baseline. If the difference between the current time and the last execution time reaches the task's cycle time, the task is executed. In fixed-frequency scheduling mode, the system uses nextScheduledTime as the planned execution time. If the current time reaches or exceeds this time, the task is executed; after the task is completed, nextScheduledTime is incremented by one cycle. When a task is detected to be lagging behind, the system resynchronizes nextScheduledTime to the current time plus one cycle.

[0061] The system uses an execution timer to track the execution time of each task. If the task execution function throws an exception, the system catches the exception and logs the error. If the execution time exceeds the alarm threshold, a task timeout alarm is issued; if the number of consecutive errors reaches the maximum number of consecutive errors, the task is automatically disabled.

[0062] Step S8: Incremental processing of monitoring data like Figure 6As shown in the flowchart on the right, the system maintains a channel buffer object for each monitoring channel. This channel buffer object includes a fixed-capacity circular buffer, an incremental buffer, a unit, the latest value, and the latest timestamp.

[0063] When a sampling point arrives, the system writes it to the circular buffer. If the circular buffer is not full, the write position is the head plus the current number of elements, modulo the result. If the circular buffer is full, a new sampling point is written, and the head pointer is moved, thus evicting the oldest sampling point. This structure makes the memory usage of the historical data cache related to the buffer capacity, preventing it from growing indefinitely over runtime.

[0064] When incremental mode is enabled, the system also appends sampling points to the incremental buffer. When the incremental buffer length exceeds the maximum incremental cache capacity, the system discards the oldest incremental point. When the amount of data in the incremental buffer reaches the batch processing threshold, the system triggers an incremental data ready event. When the UI or processing thread calls drainDelta, the system returns the current incremental point and clears the incremental buffer.

[0065] During the processing phase, the system executes a processing pipeline on the point sequence: first, it performs time window pruning; then, as needed, it performs amplitude limiting, smoothing, fixed-factor downsampling, and adaptive downsampling; finally, it limits the number of points displayed. Adaptive downsampling automatically calculates the downsampling factor based on the target number of points when the number of points exceeds a threshold, thereby reducing display overhead in high-load scenarios.

[0066] Step S9: Protocol Identification and Channel Switching like Figure 6 As shown in the flowchart on the left, the system performs protocol identification during the communication access phase. The system constructs a probe frame for each candidate protocol and sends it to the communication interface, then receives response frames and analyzes the protocol characteristics. Candidate protocols are shown in Table 6.

[0067] Table 6 Candidate Protocols After each candidate protocol is detected, protocol information is generated, including protocol type, protocol name, description, detection parameters, and confidence level. The system sorts the candidate protocols according to their confidence level and selects the protocol with the highest confidence level as the identification result. When a communication or download link needs to be established, the system can select the corresponding protocol configuration based on the identification result and execute a retry or re-identification process if it fails.

[0068] Step S10: System Implementation The present invention also provides an embedded configuration software system. This system includes a project configuration management module, a fragment library module, a semantic mapping module, a compilation normalization module, a compilation execution module, a consistency verification module, a runtime scheduling module, a monitoring data processing module, and a protocol identification module.

[0069] The project configuration management module is used to save and load the project runtime configuration; the fragment library module is used to load default fragments and project-level fragments; the semantic mapping module is used to generate DSL semantic mapping entries based on fragment insertion records; the compilation normalization module is used to generate standardized DSL input; the compilation execution module is used to generate and encapsulate compilation artifacts; the consistency verification module is used to eliminate configuration conflicts before compilation; the runtime scheduling module is used to execute runtime tasks; the monitoring data processing module is used to incrementally process sampled data; and the protocol identification module is used to identify the communication protocol type and output the corresponding protocol configuration.

[0070] Through the above embodiments, this invention achieves coordinated compilation and runtime configuration driven by DSL semantic mapping. Compared with schemes that only compile DSL text, this invention can detect configuration conflicts before compilation, trace the source of artifacts after compilation, execute tasks based on the project runtime configuration at runtime, and reduce refresh and memory pressure in high-frequency sampling scenarios through incremental monitoring.

[0071] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part 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 described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

Claims

1. A method for compiling and running configuration of embedded configuration software based on DSL semantic mapping, characterized in that, The method includes the following steps: S1, Read the project runtime configuration, which includes the DSL main script path, script file list, DSL semantic mapping list, monitoring collector provider list, variable definition list, parameter definition list, hardware resource binding list, and download artifact configuration; S2, Generate DSL segment insertion records based on the DSL segment library. The DSL segment insertion records include a unique segment identifier, segment name, mapping identifier, insertion row number, generation code, and insertion time. S3, Generate a DSL semantic mapping entry based on the DSL segment insertion record, and write the DSL semantic mapping entry into the project runtime configuration. The DSL semantic mapping entry includes a unique mapping identifier, segment identifier, channel name, signal path, physical unit, sampling period, script line number, generation code, and metadata. S4. Before compilation, perform consistency checks on the runtime configuration of the project. The consistency checks include checks on required fields of the project, duplicate checks on monitoring channels, duplicate checks on mapping identifiers, duplicate checks on signal path bindings, checks on sampling period range, checks on the integrity of variable definitions, checks on the integrity of parameter definitions, and checks on the upper limit of the number of hardware resources. S5, Perform syntax normalization processing on the DSL source file. The syntax normalization processing includes converting the instance assignment call form in the old DSL into a unified call form, converting the equal sign assignment in the function block call parameters into a standardized parameter binding form, and automatically completing the program entry point, variable declaration section and program end section when the program wrapping structure is missing. S6, call the DSL compiler to compile the normalized DSL source file input, generate compilation products, and record the product type, output path, output format, check value, source file path, main script path and script file list for the compilation products; S7. Generate a runtime task configuration based on the project runtime configuration that has passed the consistency check, and associate the runtime task configuration with the download product record of the compilation product; S8, during the running phase, based on the running task configuration, the running task is executed according to the task priority, sampling period and scheduling mode.

2. The embedded configuration software compilation and runtime configuration method based on DSL semantic mapping according to claim 1, characterized in that, The DSL fragment library includes a unique fragment identifier, fragment display name, fragment category, fragment description, DSL template code, default unit, default sampling period, and additional metadata; the additional metadata includes at least a function block type identifier and a compiler name; The DSL segment also includes at least one of memory usage and number of parameters; The DSL semantic mapping entries are uniquely identified by UUID and saved via JSON serialization. When the project is reopened, the system restores the correspondence between the DSL semantic mapping entries and DSL segments based on the unique mapping identifier and at least one of the script line number and the inserted record.

3. The method for compiling and configuring embedded configuration software based on DSL semantic mapping according to claim 1, characterized in that, The syntax normalization process includes: extracting instance names and function block types by matching the "instance name=function block type" format in the old DSL source file using regular expressions; generating an instance declaration list according to the order in which instance names appear; writing the instance names and function block types into an instance type mapping table; converting instance assignment call statements in the old DSL source file into unified call statements with instance names as the call objects; and converting the assignment symbol "=" between the parameter name and parameter value to ":=" when the bracket depth is greater than zero, the current line matches a single parameter assignment statement "parameter name=parameter value", and does not contain ":=" or "=>".

4. The method for compiling and configuring embedded configuration software based on DSL semantic mapping according to claim 1, characterized in that, When the standardized DSL source file is missing PROGRAM and END_PROGRAM, the program name is generated based on the source file name, and the PROGRAM line, VAR line, variable declaration formed by the instance declaration list, END_VAR line, and END_PROGRAM line are automatically completed.

5. The method for compiling and configuring embedded configuration software based on DSL semantic mapping according to claim 1, characterized in that, The running task configuration includes task name, priority, execution cycle, execution function or execution function reference, scheduling mode, task status, last execution time, next planned execution time, alarm threshold, maximum number of consecutive errors, and enable flag; wherein, when registering a task, the priority is limited to a preset range, the execution cycle is limited to not less than 1ms, and tasks are arranged in ascending order of priority.

6. The method for compiling and configuring embedded configuration software based on DSL semantic mapping according to claim 5, characterized in that, The scheduling modes include a fixed delay scheduling mode and a fixed frequency scheduling mode. In the fixed delay scheduling mode, the difference between the current time and the last execution completion time is used to determine whether the running task has expired. In the fixed frequency scheduling mode, the next planned execution time is used to determine whether the running task has expired, and the next planned execution time is resynchronized when the task execution is behind schedule.

7. The method for compiling and configuring embedded configuration software based on DSL semantic mapping according to claim 1, characterized in that, During the operation phase, monitoring data is acquired. The monitoring data processing during the operation phase includes: creating a fixed-capacity circular buffer and an incremental buffer for each monitoring channel; when a sampling point arrives, the sampling point is written to the circular buffer, and when incremental mode is enabled, it is written to the incremental buffer; when the number of data in the incremental buffer reaches the batch processing threshold, an incremental data ready event is triggered; during the consumption phase, the incremental buffer is retrieved and cleared; and the point sequence in the circular buffer is sequentially subjected to time window pruning, amplitude limiting, smoothing, fixed factor downsampling, adaptive downsampling, and display point limit.

8. The method for compiling and configuring embedded configuration software based on DSL semantic mapping according to claim 7, characterized in that, The circular buffer is a fixed-capacity buffer structure. When adding a sampling point, if the buffer is not full, the sampling point is written to a new position determined by the head position and the current number of elements. If the buffer is full, the new sampling point is written and the head position is moved to discard the oldest sampling point.

9. The method for compiling and configuring embedded configuration software based on DSL semantic mapping according to claim 1, characterized in that, The method further includes a protocol identification step, which includes: performing passive protocol identification based on the frame structure, length field, function code, protocol identifier field, check field, or identifier field of the frame received by the communication interface; when the confidence level of the passive protocol identification is lower than a preset threshold, and the communication interface is in an allowed probe state or within a security detection window, sending a candidate protocol probe frame to the communication interface; performing at least one of CRC16 check, MBAP header check, COB-ID range check, J1939 priority, and PGN feature parsing on the response frame; generating a confidence level for each candidate protocol, and selecting the protocol with the highest confidence level that reaches the identification threshold as the identification result to determine the corresponding communication protocol type.

10. The method for compiling and configuring embedded configuration software based on DSL semantic mapping according to claim 1, characterized in that, The compilation output is a compilation output file with the suffix .code generated based on the basic name of the DSL source file. The verification value is the SHA-256 verification value of the .code file. The metadata of the compilation output records at least the source file path, main script path, script file list, output scope, and output directory.

Images