Modularized code-free platform and construction method

Abstract

The invention relates to the technical field of software development. The invention discloses a modularized code-free platform, which adopts a five-layer architecture and comprises an application presentation layer, a test report presentation layer and a test report presentation layer, the configuration engine layer is used for analyzing the structured configuration file and generating an executable process model; the test execution layer is used for scheduling and executing a test flow defined by the process model; the hardware abstraction layer is used for providing a unified instrument operation interface and managing a mapping relation between a logic signal and physical hardware; and the equipment driving layer is used for realizing communication with specific instrument equipment. According to the method, a configuration-as-a-service mode is adopted, so that business personnel can quickly construct an application on the premise of not writing codes, the technical threshold is remarkably reduced, and the response speed is increased; business personnel only need to edit Excel to complete configuration of a complex instrument control process, and codes do not need to be written.

Description

Technical Field

[0001] This invention relates to the field of software development technology. Background Technology

[0002] Traditional software development models often require professional programmers to code, resulting in long implementation cycles, high costs, and limited involvement from business personnel, exhibiting the following drawbacks: 1) Fundamental flaws in the architectural design and severe hardware-software coupling: Most low-code platforms lack a true hardware abstraction layer in their architecture, resulting in business logic being directly bound to specific hardware points and control commands. When hardware needs to be replaced or upgraded, the business layer configuration must be manually modified accordingly, which is not only labor-intensive but also prone to introducing configuration errors, leading to poor system maintainability and scalability.

[0003] 2) Inefficient configuration and orchestration methods, lacking engineering support: The platform's process orchestration heavily relies on graphical drag-and-drop components, lacking a structured configuration method (such as a domain-specific language based on Excel) that supports batch editing, version comparison, and complex logic expression. Business models, process logic, and hardware mapping relationships are managed in a scattered manner, failing to be unified within a single configurable and verifiable framework, resulting in low configuration efficiency and difficulty in maintenance.

[0004] 3) Business models fail to be abstracted and assetized, resulting in poor reusability: Core business functions lack an independent and reusable "process model" concept, with related logic typically scattered across page scripts, UI component properties, or individual configuration items. This prevents similar functions from being abstracted into standardized modules, leading to extensive repetitive development, hindering knowledge accumulation, and impeding the accumulation and large-scale reuse of platform assets.

[0005] 4) Incomplete technological closed loop limits platform value: Existing practices often only solve localized problems, failing to build a complete closed loop from Excel -> DSL -> process model -> layered scheduling -> hardware abstraction -> plug-in driven. This disconnect prevents the platform from providing business users with an end-to-end, efficient, and error-free no-code development experience from requirements to execution.

[0006] 5) Traditional development model with high technical barriers and costs: Essentially, many platforms still rely on professional programmers for coding or deep configuration, resulting in long development cycles and high costs. The participation of business personnel (domain experts) is severely limited, making it impossible for them to directly and autonomously transform business knowledge into executable applications, thus failing to truly achieve a "business-driven" development paradigm shift.

[0007] These challenges mean that low-code platforms have not truly improved the work efficiency of business users, resulting in low platform usage. Therefore, researching an easy-to-operate, reusable, and scalable process-model-based no-code platform has become an important topic in the digital transformation process. Summary of the Invention

[0008] The purpose of this invention is to provide a modular no-code platform and its construction method, which enables business personnel to quickly build applications without writing code in a configuration-as-a-service manner, significantly reducing the technical threshold and improving response speed.

[0009] To address the aforementioned technical problems, this invention provides a modular no-code platform employing a five-layer architecture, comprising: Application presentation layer: used to provide user interface and test report display; Configuration engine layer: used to parse structured configuration files and generate executable process models; Test Execution Layer: Used to schedule and execute the test processes defined by the process model; Hardware Abstraction Layer: Used to provide a unified instrument operation interface and manage the mapping relationship between logic signals and physical hardware; Device driver layer: Used to enable communication with specific instruments and devices; in, The configuration engine layer supports configuration via Excel templates and converts the configuration content into a domain-specific language description. The hardware abstraction layer maintains a dot number mapping table and manages various instrument drivers through a plug-in approach.

[0010] The hardware abstraction layer includes: A unified instrument interface defines standard methods for initialization, parameter setting, command execution, data reading, and data writing. The dot mapping table is used to store the mapping relationship between logical signal names and physical hardware channel addresses; A plug-in driver manager is used to dynamically load instrument driver plug-ins that implement a unified instrument interface.

[0011] The Excel template parsed by the configuration engine layer contains at least three independent worksheets, which are used to define the process module library, orchestrate the test process sequence, and configure the hardware point number mapping relationship, respectively.

[0012] It includes a process model library for storing and managing process modules; each process module is an atomic business function unit with a unique identifier, well-defined input and output parameters and constraint rules; the test process is composed of multiple process modules combined according to the dependencies and control logic generated by the configuration engine layer.

[0013] The process modules in the process model library support version management, and the test process combines business functions by referencing specific version identifiers of the process modules.

[0014] A construction method based on the above platform includes the following steps: ① Business personnel define process modules, orchestrate test steps, and configure hardware mapping relationships in the structured configuration template; ② The configuration engine layer loads and verifies the configuration template, parses it, and generates an executable process model; ③ The test execution layer loads and runs the process model, and schedules tasks according to dependencies; ④ During execution, the hardware abstraction layer converts logical operation instructions into calls to specific instrument drivers based on the point number mapping table; ⑤ The test results are fed back to the application presentation layer in real time for display and recording.

[0015] In step ①, the structured configuration template is an Excel file, and business personnel complete the process module definition, process arrangement and hardware mapping in different preset worksheets.

[0016] In step ②, generating an executable process model includes: converting the Excel configuration content into an intermediate JSON structure, performing syntax and dependency verification, and finally constructing an executable task tree composed of process module nodes with execution order and conditional logic.

[0017] In step ④, when the hardware device is replaced, it is only necessary to update the physical address information in the point number mapping table in the hardware abstraction layer and load the corresponding new driver plugin, without modifying the business process configuration.

[0018] Compared to existing technologies, this invention uses a configuration-as-a-service approach, enabling business personnel to quickly build applications without writing code, significantly lowering the technical threshold and improving response speed. Business personnel only need to edit Excel files to complete the configuration of complex instrument control processes without writing code. The plug-in driver enables the rapid access of new instruments, and hardware upgrades only require providing the corresponding adapter plug-in. The process module library enables the modularization and composability of business functions, supporting cross-project reuse.

[0019] The above description is merely an overview of the technical solution of the present invention. In order to better understand the technical means of the present invention and to implement it in accordance with the contents of the specification, and in order to make the above and other objects, features and advantages of the present invention more apparent and understandable, specific embodiments of the present invention are described below. Attached Figure Description

[0020] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0021] Figure 1 This is an architecture diagram of the platform of this invention; Figure 2 This is a diagram showing the relationship between the core components of the hardware abstraction layer of this invention.

[0022] Figure 3 This is a classification structure diagram of the process model library of this invention. Detailed Implementation

[0023] To make the objectives, technical solutions, and advantages of this invention clearer, the embodiments of this invention will be described in detail below with reference to the accompanying drawings. However, those skilled in the art will understand that many technical details are presented in the embodiments of this invention to facilitate a better understanding of this application. However, the technical solutions claimed in this application can be implemented even without these technical details and various variations and modifications based on the following embodiments. The division of the following embodiments is for ease of description and should not constitute any limitation on the specific implementation of this invention. The embodiments can be combined with and referenced by each other without contradiction.

[0024] This invention is a layered architecture design based on a modular process model, which enables business personnel to complete hardware abstraction, process orchestration and test execution through configuration files.

[0025] like Figure 1 As shown, the no-code development platform adopts a layered architecture design, consisting of the application presentation layer, configuration engine layer, test execution layer, hardware abstraction layer, and device driver layer from top to bottom. The application presentation layer serves as the interaction window between the platform and the user, including the execution interface, report presentation, and soft panels; the configuration engine layer is responsible for parsing and verifying the configuration file content and converting it into an internally executable sequence model; the test execution layer is responsible for scheduling, executing, and monitoring the test process; the hardware abstraction layer unifies the operation interfaces of various instruments, encapsulating different instruments into a unified operation interface for use by the upper layers; the device driver layer directly interacts with the hardware, realizing the lowest-level device control and providing the upper layers with raw device access capabilities.

[0026] Main principles explained: 1. Hardware Abstraction Layer Design The Hardware Abstraction Layer (HAL) primarily addresses the issues of inconsistent hardware interfaces and diverse protocols across different manufacturers. Hardware operations are standardized into basic functions such as open, read / write, and close. A software panel is built upon these basic operations to manage hardware resources and enable software panel invocation. Core components of the HAL include... Figure 2 As shown.

[0027] Unified Interface: Define a unified Instrument interface, including methods such as initialize(), setParameter(), execute(), readData(), and writeData(). All instruments implement this interface through the adapter pattern, achieving a unified abstraction of hardware operations.

[0028] Point number abstraction: The internal hardware abstraction object is maintained using a point number mapping table. The business layer only operates on the logical name, and changes to the point number only need to be updated internally, ensuring the decoupling between the platform and the hardware.

[0029] Plug-in driver: The driver implementation for each instrument is packaged as a plug-in, which is dynamically loaded when the platform starts. The plug-in declares the hardware models it supports and the corresponding point number mappings, enabling plug-and-play functionality.

[0030] 2. Configuration resolution and execution design By parsing standard configuration templates, the test process, execution logic, and verification standards are organically integrated. Based on topological sorting, dependencies are resolved to generate executable test sequences. The scheduler utilizes a thread pool for parallel scheduling and automatically triggers subsequent tasks upon completion of the current task. Configurable actions are available for each module to perform, such as retrying, skipping, or stopping tests if execution fails, ensuring the robustness of the overall process. Visual aids and annotations enhance the visualization and traceability of the testing process. The parsing steps are as follows: 1) Load the configuration file; 2) Basic structure verification; 3) Create global variables; 4) Construct a hardware resource pool; 5) Analyze the original steps; 6) Construct the control flow; 7) Expression parsing; 8) Dependency building; 9) Integrity verification; 10) Generate the execution sequence.

[0031] 3. Process Model Library Design The process model adopts a multi-level classification design, and the classification structure diagram is as follows: Figure 3 As shown.

[0032] Each business function is abstracted into a "process module", corresponding to a record. The record fields include: module ID (unique), module name, input and output data structure, constraint rules, etc.

[0033] The process library stores complete business processes. Each record consists of different process modules. Record fields include: unique ID, process name, module sequence, conditional branch expression, loop control parameters, associated hardware abstract objects, etc.

[0034] Each process model library defines different actions, such as basic scripts for controlling power supply voltage and outputting it, and detecting the on / off state of a signal, for use by business technicians. Business technicians only need to focus on the operating steps and interface definitions of the device being debugged, without needing to worry about the underlying details.

[0035] In summary, compared with traditional low-code platform technologies, this invention has the following advantages: ① Hardware Abstraction Layer + Dot Mapping Table: Instrument interfaces are uniformly defined at the platform's underlying layer. All business logic uses only logical names. Dot mapping is centrally managed in the hardware abstraction layer. When hardware is replaced, only the mapping table needs to be updated, and the business layer does not need to be modified.

[0036] ② Excel-DSL Dual Mapping: Business personnel maintain module libraries, process orchestration, and hardware mapping tables in Excel. The platform generates JSON Schema and DSL through a parser, which retains the advantages of Excel's batch editing while realizing a structured and verifiable configuration method.

[0037] ③ Modularization and Versioning: Each business function is abstracted into an independent process model, possessing a unique ID, input / output content, constraint rules, and optional scripts. The module library supports multiple versions coexisting, and the testing process combines them by referencing the process model ID, achieving "define once, reuse everywhere."

[0038] Those skilled in the art will understand that the above embodiments can be modified in form and detail in practical applications without departing from the spirit and scope of the invention.

Claims

1. A modular no-code platform, characterized in that: It adopts a five-layer architecture, including: Application presentation layer: used to provide user interface and test report display; Configuration engine layer: used to parse structured configuration files and generate executable process models; Test Execution Layer: Used to schedule and execute the test processes defined by the process model; Hardware Abstraction Layer: Used to provide a unified instrument operation interface and manage the mapping relationship between logic signals and physical hardware; Device driver layer: Used to enable communication with specific instruments and devices; in, The configuration engine layer supports configuration via Excel templates and converts the configuration content into a domain-specific language description. The hardware abstraction layer maintains a dot number mapping table and manages various instrument drivers through a plug-in approach.

2. The modular no-code platform as described in claim 1, characterized in that: The hardware abstraction layer includes: A unified instrument interface defines standard methods for initialization, parameter setting, command execution, data reading, and data writing. The dot mapping table is used to store the mapping relationship between logical signal names and physical hardware channel addresses; A plug-in driver manager is used to dynamically load instrument driver plug-ins that implement a unified instrument interface.

3. The modular no-code platform as described in claim 1, characterized in that: The Excel template parsed by the configuration engine layer contains at least three independent worksheets, which are used to define the process module library, orchestrate the test process sequence, and configure the hardware point number mapping relationship, respectively.

4. The modular no-code platform as described in claim 1 or 3, characterized in that: It includes a process model library for storing and managing process modules; each process module is an atomic business function unit with a unique identifier, well-defined input and output parameters and constraint rules; the test process is composed of multiple process modules combined according to the dependencies and control logic generated by the configuration engine layer.

5. The modular no-code platform as described in claim 4, characterized in that: The process modules in the process model library support version management, and the test process combines business functions by referencing specific version identifiers of the process modules.

6. A method for constructing a platform based on any one of claims 1 to 5, characterized in that: Includes the following steps: ① Business personnel define process modules, orchestrate test steps, and configure hardware mapping relationships in the structured configuration template; ② The configuration engine layer loads and verifies the configuration template, parses it, and generates an executable process model; ③ The test execution layer loads and runs the process model, and schedules tasks according to dependencies; ④ During execution, the hardware abstraction layer converts logical operation instructions into calls to specific instrument drivers based on the point number mapping table; ⑤ The test results are fed back to the application presentation layer in real time for display and recording.

7. The construction method as described in claim 6, characterized in that: In step ①, the structured configuration template is an Excel file, and business personnel complete the process module definition, process arrangement and hardware mapping in different preset worksheets.

8. The construction method as described in claim 6, characterized in that: In step ②, generating an executable process model includes: converting the Excel configuration content into an intermediate JSON structure, performing syntax and dependency verification, and finally constructing an executable task tree composed of process module nodes with execution order and conditional logic.

9. The construction method as described in claim 6, characterized in that: In step ④, when the hardware device is replaced, it is only necessary to update the physical address information in the point number mapping table in the hardware abstraction layer and load the corresponding new driver plugin, without modifying the business process configuration.

Images