Software automation construction system and method oriented to proton treatment system and related equipment

Abstract

The invention discloses an automatic software construction system and method for a proton treatment system and related equipment, and relates to the technical field of computers, the system comprises a construction management server deployed on a first operating system platform; the plurality of heterogeneous construction nodes are in communication connection with the construction management server; wherein the construction management server is configured to receive a construction request submitted by a user, and the construction request at least comprises a to-be-constructed software component set; in response to the construction request, issuing a construction instruction to the corresponding heterogeneous construction node; the construction instruction drives the construction node to forcibly execute static code analysis on source codes of the software component set, and compiling and packaging are executed after the analysis is passed; the problems of fragmentation, high integration complexity and the like in proton treatment system software construction are solved, and a reliable and efficient automatic construction system meeting the requirements of laws and regulations is provided for medical equipment software.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to an automated software development system, method, and related equipment for proton therapy systems. Background Technology

[0002] As a high-precision tumor treatment device, the proton therapy system is extremely complex, encompassing multiple key subsystems including treatment control, patient positioning, radiofrequency control, superconducting magnet modulation, ion source management, beam scanning, dose monitoring, rack control, and safety interlocks. The software components of these subsystems are developed based on diverse technology stacks, involving different operating systems such as Windows, Red Hat, and Linux, as well as various programming languages ​​and development frameworks. The system comprises more than 20 independent software components, each with significant differences in functional logic, dependencies, and deployment requirements.

[0003] Currently, the development process of proton therapy system software is highly dependent on manual operation. Developers need to frequently switch between different operating system platforms (such as Windows servers and Linux virtual machines) and manually perform a series of steps such as code retrieval, version number entry, compilation parameter configuration, and packaging. Moreover, the recording of version type and build number relies entirely on manual ledgers, which makes it extremely easy for operational negligence to lead to version confusion, omission of build steps, or incorrect parameter configuration.

[0004] Due to the lack of a unified, standardized build framework, the build processes of each subsystem are fragmented. Build scripts are written independently, dependency management methods vary, and environment configuration lacks standardized specifications. This makes the entire system integration and build process complex and fragile, highly dependent on the experience of the operators, and even slight deviations can lead to integration failures. Furthermore, the cross-platform heterogeneity of the system software further exacerbates the integration difficulty. Binary files, dynamic link libraries, and configuration files generated under different operating systems require manual adaptation and integration, making it difficult to guarantee the consistency and correctness of the integration results, severely restricting efficiency in large-scale development scenarios.

[0005] There may be shortcomings in the security and compliance of medical device software code. In the existing process, code security vulnerability scanning and programming standard compliance checks are often independent of the build process, and are mostly optional post-operations, or even rely on developers to perform them independently. As a result, potential security risks or non-compliance issues are difficult to be discovered in a timely manner during the build phase, and are often delayed until the later stages of testing or even the actual deployment phase, which increases the cost of remediation. Summary of the Invention

[0006] In view of the above problems, the purpose of this invention is to provide an automated software construction system, method and related equipment for proton therapy systems, providing a reliable, efficient and regulatory compliant automated construction system for medical device software.

[0007] In a first aspect, the present invention provides an automated software construction system for proton therapy systems, the system comprising: Build a management server and deploy it on the first operating system platform; Multiple heterogeneous build nodes are communicatively connected to the build management server; The build management server is configured as follows: Receive a build request submitted by a user, the build request including at least a set of software components to be built; In response to the build request, a build instruction is issued to the corresponding heterogeneous build node; The build instruction drives the build node to perform static code analysis on the source code of the software component set, and compiles and packages the code after the analysis is successful.

[0008] Preferably, the build management server is a Jenkins-based platform and communicates and transfers files with the build nodes via the SSH protocol; the first operating system platform is a Windows operating system platform; the heterogeneous build nodes include at least build nodes running on Linux and build nodes running on Windows.

[0009] Preferably, the build node running on the Linux system includes at least one Red Hat virtual machine, which is pre-configured with SSH service and has port 22 open, and connects to the build management server via key authentication.

[0010] Preferably, the build node includes multiple virtual machines, each virtual machine is pre-configured with a dedicated build user and permissions, and is authenticated with the build management server via an SSH key pair; wherein, the build management server verifies the communication status with the build node by testing the connection.

[0011] Preferably, the build instruction is configured to drive the build node to complete the static code analysis before performing the compilation operation; if the analysis does not detect defects of a preset level, the compilation and packaging operations continue; otherwise, the build process is interrupted and the current build is marked as a failure; wherein, the static code analysis includes code security scanning and compliance checks to identify security vulnerabilities and violations of programming standards.

[0012] Preferably, the build request further includes a build type; the build management server is configured to select and issue instructions to the corresponding heterogeneous build nodes based on the software component set and the build type.

[0013] Preferably, the build management server is further configured to: automatically generate or update a version identifier after responding to the build request; and drive the build node to create a version tag in the code repository based on the version identifier; wherein the version identifier is automatically generated or updated through a version management script, and the version management script performs version number iteration according to the build type and preset coding rules.

[0014] Preferably, the build instruction is designed to drive the build node to perform the following operations in sequence: first, obtain the source code of the specified component from the code repository, then perform the static code analysis, and after the analysis is successful, perform compilation and packaging operations.

[0015] Preferably, the software components in the software component set include at least one of a treatment control module, an image acquisition module, an accelerator control module, a dose measurement control module, and a radio frequency control module; wherein each software component corresponds to an independent code repository branch, and the build instruction pulls the source code of the corresponding branch according to the user's selection.

[0016] Preferably, the build management server includes: The software version management module is used to maintain and manage the version information and build configuration information of the software. A task configuration module is built to receive the build request; An integrated build engine is used to execute the issuance of build instructions and control the process.

[0017] Preferably, the software version management module generates a visual interface through the HTML Publisher plugin to display and edit version types, build numbers, and software components; the build task configuration module receives user requests through parameterized build methods, wherein the software component set is provided in the form of checkboxes, and the build type is specified through drop-down menus or single-line text boxes.

[0018] Preferably, the build task configuration module receives user requests through a parameterized build format, wherein the software component set is provided in the form of checkboxes, and the build type is specified through a single-line text box or a drop-down menu.

[0019] In a second aspect, the present invention provides an automated software construction method for proton therapy systems, the method comprising: The system receives build requests submitted by users through a build management server, and the build requests include at least a set of software components to be built. In response to the build request, build instructions are issued to heterogeneous build nodes through the build management server; The build instructions drive the build nodes to perform static code analysis on the source code of the software component set, and compile and package the code after the analysis is successful.

[0020] Thirdly, the present invention provides an electronic device, the electronic device including a memory and a processor, the memory storing a computer program, the processor executing the computer program to perform the functions of any of the systems described in the present invention or to implement the steps of the methods described in the present invention.

[0021] Fourthly, the present invention provides a computer-readable storage medium that stores computer instructions, wherein when a computer reads the computer instructions, the computer performs the functions of any of the systems described in the present invention or implements the steps of the methods described in the present invention.

[0022] Compared with existing technologies, this invention solves the problems of fragmentation and high integration complexity in the construction of proton therapy system software. The beneficial effects of this invention include at least the following: achieving collaborative construction between Windows and Red Hat heterogeneous platforms through a unified construction management server, standardizing the construction process of scattered subsystems, replacing manual operation, reducing integration errors caused by platform differences and chaotic dependency management, significantly improving the efficiency and consistency of multi-module (treatment control, dosage measurement, etc.) integration, ensuring the repeatability of release versions, and improving construction efficiency.

[0023] Strengthening medical-grade security and compliance, and reducing risk costs, static code analysis is made a rigid step before compilation. Combined with a dedicated rule base for proton therapy systems (such as dose calculation accuracy and control command permission verification), security vulnerabilities and compliance issues can be discovered early, preventing risks from being left over to the testing or deployment stage. This reduces security risks caused by software defects from the source and ensures the safety of the proton therapy system.

[0024] Intelligent optimization of build quality and resource scheduling balances reliability and efficiency. Through correlation analysis, defect judgment thresholds are dynamically adjusted; machine learning predicts key defect risks; and a self-optimizing closed-loop management logic continuously evolves to proactively improve build quality. Combined with the differentiated needs of build types, resources are precisely scheduled based on node capability profiles to improve iteration efficiency while ensuring medical-grade reliability. Attached Figure Description

[0025] Figure 1 This is a schematic diagram of the software automated construction system structure for a proton therapy system according to an embodiment of the present invention; Figure 2 This is a schematic diagram of an automated software construction method for a proton therapy system according to an embodiment of the present invention; Figure 3 This is a schematic diagram of the automated software construction process for a proton therapy system according to an embodiment of the present invention. Detailed Implementation

[0026] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the embodiments set forth herein; rather, they are provided to make the invention more comprehensive and complete, and to fully convey the concept of the exemplary embodiments to those skilled in the art. The same reference numerals in the drawings denote the same or similar structures, and therefore repeated descriptions of them will be omitted.

[0027] The terms used to express position and direction in this invention are illustrated with reference to the accompanying drawings, but changes can be made as needed, and all such changes are included within the scope of protection of this invention.

[0028] See appendix Figure 1 Example 1: This invention provides an automated software construction system for proton therapy systems, the system comprising: Build a management server and deploy it on the first operating system platform; Multiple heterogeneous build nodes are communicatively connected to the build management server; The build management server is configured as follows: Receive build requests submitted by users (developers), the build requests including at least a set of software components to be built; In response to the build request, a build instruction is issued to the corresponding heterogeneous build node, i.e., the heterogeneous build node; The build instruction drives the build node to perform static code analysis on the source code of the software component set, and compiles and packages the code after the analysis is successful.

[0029] The working principle of the above technical solution is as follows: The user submits a build request to the build management server deployed on the first operating system platform. The core of this request is to specify the set of software components that need to be built. The build management server responds to this request but does not directly execute the build operation. Instead, based on the request content, it issues unified build instructions to the multiple heterogeneous build nodes that are connected to it.

[0030] Upon receiving instructions, the build node is driven to execute a strictly sequential, unavoidable automated process: First, mandatory static code analysis is required: the build node must perform static code analysis on the source code of the target software component set. This step is a prerequisite and quality gate for subsequent operations.

[0031] Then, compilation and packaging are performed conditionally: the build node continues to perform compilation and packaging operations to generate the final software artifact only if the static code analysis passes (i.e., no defects of the preset level are detected). If the analysis fails, the build process is interrupted here.

[0032] The effects of the above technical solution are as follows: By introducing a build management server as the sole scheduling center, the fragmentation problem caused by software components being deployed on different operating systems (heterogeneous nodes) in traditional build methods is overcome. Regardless of the platform on which the software component runs, its build requests are submitted through a unified entry point, scheduled by a unified server, and follow a unified analysis, compilation, and packaging instruction flow, thereby achieving standardization and consistency in the build process.

[0033] By setting static code analysis as a mandatory pre-compilation process driven by build instructions, it ensures that every successfully built software version has undergone rigorous pre-construction quality screening. This completely changes the awkward situation where static analysis is often relegated to an after-the-fact or optional role in traditional processes, enabling early detection and prevention of security vulnerabilities and coding defects, which is crucial for medical device software with high reliability requirements, such as proton therapy systems.

[0034] The two originally separate activities of software building and code quality analysis are seamlessly integrated into an automated continuous process; this not only reduces human intervention and lowers the risk of omissions or errors in operation, but also greatly improves the overall efficiency from code submission to final product output, providing stable and reliable underlying support for rapid iterative development.

[0035] In one possible implementation, the build management server is a Jenkins-based platform and communicates with the build nodes and transfers files via the SSH protocol; the first operating system platform is a Windows operating system platform; the heterogeneous build nodes include at least build nodes running Linux and build nodes running Windows.

[0036] In one possible implementation, the build node running on a Linux system includes at least one Red Hat virtual machine, which is pre-configured with SSH service and has port 22 open, and connects to the build management server via key authentication.

[0037] In one possible implementation, the build node includes multiple virtual machines, each pre-configured with a dedicated build user and permissions, and authenticated with the build management server via an SSH key pair; wherein the build management server verifies the communication status with the build node by testing the connection.

[0038] Using the Jenkins platform deployed on the Windows operating system as the nerve center of the entire system, Jenkins establishes communication links with all heterogeneous build nodes through the standard and secure SSH protocol, enabling the issuance of build commands, file transfer, and monitoring of execution status.

[0039] For build nodes running on Linux systems (specifically Red Hat virtual machines), secure and seamless integration is achieved by pre-configuring SSH service, opening port 22, and using key-based authentication to connect to the Jenkins server. This solution also applies to other build nodes (including Windows nodes). By configuring them as virtual machines and pre-configuring dedicated build users and permissions for each virtual machine, while using SSH key pairs for authentication, it ensures that each build environment is isolated, clean, and has controlled permissions.

[0040] Before the build process begins, the build management server (Jenkins) proactively verifies the communication status with all build nodes by testing the connection function, ensuring that the foundation of the entire automated pipeline is solid and avoiding unexpected interruptions to the build process due to network or authentication issues.

[0041] The effects of the above technical solution are as follows: By employing the SSH protocol and its key authentication mechanism, all instructions and data transmissions between the build management server and all build nodes are encrypted, effectively preventing sensitive code and build artifacts from being stolen or tampered with during transmission, thus meeting the high security requirements of medical software. Furthermore, this protocol is a cross-platform standard, ensuring consistency and reliability of communication with different systems such as Windows and Linux (Red Hat).

[0042] By unifying the build nodes as virtual machines and pre-configuring dedicated build users and permissions for each node, the infrastructure as code of the build environment is realized. This means that the build environment can be quickly and consistently copied and rebuilt, completely eliminating the uncertainty of build results caused by differences in physical machine configurations, ensuring the repeatability of each build, and providing a clean context for problem tracing.

[0043] By adopting the mature open-source platform Jenkins as its core, the system leverages its rich plugin ecosystem, powerful scheduling engine, and user-friendly interface, significantly reducing the complexity of system development and maintenance. The upfront communication status testing function can quickly locate and troubleshoot network and authentication problems, transforming operations and maintenance from reactive to proactive, and significantly improving the availability and operational efficiency of the entire build system.

[0044] In one possible implementation, the build instruction is configured to drive the build node to complete the static code analysis before performing the compilation operation; if the analysis does not detect defects of a preset level, the compilation and packaging operations continue; otherwise, the build process is interrupted and the current build is marked as a failure; wherein, the static code analysis includes code security scanning and compliance checks to identify security vulnerabilities and violations of programming standards.

[0045] The build instructions are explicitly configured to drive the build node to perform static code analysis first, before proceeding with subsequent compilation operations. This order is fixed in the instruction logic and cannot be reversed or skipped, ensuring that quality checks are absolutely prioritized.

[0046] The system has a built-in automatic decision point, which is determined by analyzing whether a defect of a preset level has been detected. Condition met (passed): The instruction logic-driven process continues, executing compilation and packaging operations; If the condition is not met (failure): the instruction logic immediately interrupts the build process and marks the current build as a failure. This forms an automated, unbypassable quality gate.

[0047] The static code analysis mentioned above is not just a general discussion; it specifically covers code security scanning (used to identify potential security vulnerabilities, such as buffer overflows and injection attacks) and compliance checks (used to discover code that violates programming standards). This makes the goals of quality control very clear and comprehensive, and more effectively improves the quality control results.

[0048] In one possible implementation, the build request further includes a build type; the build management server is configured to select and issue instructions to the corresponding heterogeneous build nodes based on the software component set and the build type.

[0049] The build types include RELEASE_BUILD (release build), TEST_BUILD (test build), and DAILY_BUIL (daily build).

[0050] In addition to specifying the set of software components to be built, users must also clearly define the build type (such as official build, beta build, or daily build) in their build requests to ensure that the build intent and objectives are accurately communicated.

[0051] When responding to requests, the build management server's decision-making logic no longer relies solely on what to build, but also on why it's building. Based on two key parameters—the software component set and the build type—it selects the most suitable heterogeneous build node through a preset scheduling strategy.

[0052] For example, a final build of a treatment control module might be scheduled to run on a clean, stable, and higher-performance cluster of build nodes; while daily builds of the same module might be scheduled to general-purpose build nodes for rapid daily feedback.

[0053] Based on the results of the above strategic selection, the build management server issues build instructions to the finally determined, corresponding heterogeneous build nodes, thereby ensuring that the build task is executed in the environment most suitable for its goals and requirements.

[0054] The effects of the above technical solution are as follows: By identifying build types, the system can direct build tasks with different importance and quality requirements to the most suitable computing resources. This ensures that critical tasks, such as official builds, which affect the quality of the final deliverable, receive the most stable and reliable build environment; at the same time, it allows frequently performed tasks, such as daily builds, to be completed quickly without consuming critical resources, thus maximizing resource utilization efficiency.

[0055] This mechanism provides the technical foundation for implementing differentiated quality gates across different build types (such as enforcing stricter static code analysis rules for production builds). This makes quality management more flexible and targeted, ensuring both the ultimate reliability of the final product and the efficiency requirements of rapid iteration during development.

[0056] By transforming the business concept of build type into a system-recognizable scheduling parameter, human decision-making and arbitrariness in the build process are reduced. Developers and release managers can clearly know that builds for different purposes will automatically follow preset, standardized paths, enhancing the standardization and predictability of the entire software development process.

[0057] In one possible implementation, the build management server further includes a node scheduling optimization module, which is configured to: Maintain a build node capability profile library to store static configuration information and dynamic operating metrics for each build node; Determine resource requirement preferences based on the construction type; Based on the resource demand preferences, a weighted algorithm is used to calculate the fit score between each candidate node and the current construction task. Select the node with the highest fitness score as the target node; The static configuration information includes the number of CPU cores, memory capacity, and operating system version; The dynamic performance metrics include current CPU load, available memory, and historical build success rate.

[0058] In one possible implementation, the node scheduling optimization module is further configured as follows: When the build type is RELEASE_BUILD, the resource requirement preference is set to reliability first, and the historical build success rate metric is assigned the highest weight in the weighted algorithm. When the build type is DAILY_BUILD, the resource requirement preference is set to efficiency first, and the current CPU load and available memory metrics are assigned the highest weight in the weighted algorithm.

[0059] In one possible implementation, the weighted algorithm also incorporates the historical average build time of the node for the set of software components as a calculation factor when calculating the fit score.

[0060] The node scheduling optimization module is also configured to: After the target node completes the construction task, its corresponding dynamic operation indicators are updated based on the actual results of this construction.

[0061] The effects of the above technical solution are as follows: By pre-setting differentiated resource requirement preferences and weighting strategies for different build types (such as RELEASE_BUILD and DAILY_BUILD), the system can automatically schedule the official build with the highest reliability requirements to be executed on the node with the highest historical build success rate and the most stable performance. This provides deterministic resource guarantees for medical software releases that are crucial to treatment safety, greatly reducing the possibility of potential risks introduced due to unreliable build environments from the infrastructure level.

[0062] By comprehensively considering the static configuration information of nodes (such as CPU and memory) and dynamic operating indicators (such as real-time load and historical success rate), and by dynamically adjusting the weights of different indicators, the system can intelligently make the optimal trade-off between different goals such as rapid response (for daily builds) and stability and reliability (for official builds). This not only ensures the efficient execution of the build task itself, but also optimizes the overall resource utilization of the heterogeneous computing cluster from a global perspective.

[0063] The key to this design is that after each build, the system dynamically updates the node's capability profile based on the actual build results. This allows scheduling decisions to move beyond initial, fixed configurations and dynamically adjust based on real-time node performance and historical data. The system can automatically identify and prioritize nodes with better performance, ensuring that the overall efficiency and reliability of the build system continuously improve over time.

[0064] By introducing the historical average build time of a node for a specific set of software components as a calculation factor, the scheduling strategy can be refined from general type matching to task matching. This means that the system can intelligently select the node with the fastest build speed in the past for a specific, complex software module (such as a treatment control module), thereby further squeezing the time cost of the build process at the micro level and improving the speed of development iteration.

[0065] In one possible implementation, the build management server is further configured to automatically generate or update a version identifier in response to the build request; and drive the build node to create a version tag in the code repository based on the version identifier; wherein the version identifier is automatically generated or updated by a version management script, which iterates the version number according to the build type and preset coding rules.

[0066] Once the build management server responds to the build request, it will immediately trigger a version control script. This script, acting as the logic engine for version control, will automatically calculate and generate a new, unique version identifier based on the build type (such as a production build, a test build, etc.) and a set of preset coding rules.

[0067] For example, the script logic might specify that a RELEASE_BUILD will increment the major version number by one, while a TEST_BUILD will only iterate over the build number.

[0068] Version number updates are not arbitrary, but are executed by scripts strictly following preset coding rules. This ensures that version number iterations (such as from v1.0.0 to v1.1.0) are logical, predictable, and conform to semantic version management specifications, completely eliminating the confusion and errors that may be caused by manual operation.

[0069] After a new version identifier is generated, the build management server will drive the build nodes to execute a command such as `git tag -a [new version identifier]` on the source code pulled from the code repository, creating a permanent version tag in the code repository based on that version identifier.

[0070] Through the above process, the system establishes a precise mapping relationship between the build request, the source code snapshot used for compilation, and the final software artifact, which is connected by a unique version identifier. This is equivalent to giving each build a unique ID card and achieving traceability throughout the entire lifecycle.

[0071] The effects of the above technical solution are as follows: Version management scripts automatically iterate version numbers based on build type and preset coding rules, eliminating version number errors, duplications, or omissions caused by manual recording and modification. Regardless of how many heterogeneous nodes the build process runs in parallel, all components are built based on the same authoritative version identifier, ensuring the uniqueness and consistency of software versions throughout the entire system from the root.

[0072] By driving build nodes to create version tags based on version identifiers in the code repository, the system establishes an immutable and precise mapping between a specific source code state, a unique version identifier, and the final generated software artifact, providing a complete and auditable version hierarchy for proton therapy software. When troubleshooting, impact analysis, or compliance audits are required, the entire source code that produced the artifact can be quickly and accurately located, greatly satisfying the mandatory traceability requirements in the lifecycle management of medical device software.

[0073] Seamlessly embedding version identifier generation and tagging operations into the automated build pipeline eliminates manual and repetitive work for developers in this stage. This not only improves build efficiency but also avoids the risk of version identifiers not matching the actual code due to human error or incorrect process execution order, making the entire software delivery process more standardized, reliable, and efficient.

[0074] In one possible implementation, the build instructions are designed to drive the build node to perform the following operations in sequence: first, obtain the source code of the specified component from the code repository, then perform the static code analysis, and after the analysis is successful, perform compilation and packaging operations.

[0075] By setting static code analysis as a mandatory gate that must be passed before compilation, the process ensures that any code that fails to meet quality standards can never be compiled into a software artifact. This establishes an automated and unbypassable security defense for the proton therapy system software, preventing the release of versions with known static defects from the source and greatly improving the inherent security and reliability of the software.

[0076] By screening code quality at the very beginning of the build process (before compilation), security vulnerabilities and coding style violations can be discovered as early as possible in the development cycle. The cost of fixing these issues at this stage is minimal, requiring only modifications to the source code. This avoids the massive rework, version rollbacks, and project delays that occur when problems are discovered only after testing, integration, or even deployment.

[0077] The system solidifies multiple steps that might otherwise be flexibly controlled manually into a strict linear sequence driven by unified instructions, eliminating the uncertainty of results caused by arbitrary operation order. Regardless of who triggers the build or when, the system follows the same standardized process of quality checking first, followed by production build, thus ensuring a high degree of consistency and repeatability of build process and output quality for each time.

[0078] In one possible implementation, the software components in the software component set include at least one of a treatment control module, an image acquisition module, an accelerator control module, a dose measurement control module, and a radio frequency control module; wherein each software component corresponds to an independent code repository branch, and the build instruction pulls the source code of the corresponding branch according to the user's selection.

[0079] The software component set in the user-submitted build request consists of key functional modules such as treatment control, image acquisition, accelerator control, dose measurement control, and radio frequency control. After receiving these module selections, the build management server maps them to preset configurations.

[0080] Each software component maintains its own independent code repository branch (for example, the therapy-control-branch corresponds to the therapy-control-branch for the therapy control module). When the build command drives the build node, it does not fetch the entire repository's code, but rather fetches the source code of the specific branch selected by the user. This means that the build node's workspace will only contain the code of the specific branch related to the selected component.

[0081] After obtaining the source code of a specified branch, subsequent static code analysis, compilation, and packaging operations will be completed independently based on this branch's code. This ensures that the build processes of different modules are logically and physically isolated, without interfering with each other.

[0082] The effects of the above technical solution are as follows: Users can freely choose any combination of one or more modules to build, without compiling the entire system. This greatly improves build flexibility, precisely meeting the needs of specific module development, debugging, integration testing, or hotfix release scenarios, avoiding the time and resource waste caused by a full build.

[0083] Because each component corresponds to an independent code repository branch, and combined with the aforementioned precise pull mechanism, development teams for different modules can work in parallel on their respective branches. When a build is needed, the system ensures that only the code of the target branch is fetched and built, thereby isolating code changes and potential build risks within a specific module and avoiding mutual influence and build failures caused by code coupling between modules or branch confusion.

[0084] Each commit to each module branch can independently trigger a build process that includes static code analysis and compilation, ensuring the quality within the module. This divide-and-conquer strategy makes it easier to discover and locate problems early, ultimately providing a reliable guarantee for the high-quality, high-efficiency integration and delivery of the entire proton therapy system.

[0085] In one possible implementation, the build management server includes: The software version management module is used to maintain and manage the version information and build configuration information of the software. A task configuration module is built to receive the build request; An integrated build engine is used to execute the issuance of build instructions and control the process.

[0086] In one possible implementation, the software version management module generates a visual interface through an HTML Publisher plugin to display and edit version types, build numbers, and software components; the build task configuration module receives user requests through parameterized builds, wherein the set of software components is provided in the form of checkboxes, and the build type is specified through a drop-down menu or a single-line text box.

[0087] In one possible implementation, the build task configuration module receives user requests via a parameterized build format, wherein the set of software components is provided as checkboxes, and the build type is specified via a single-line text box or a drop-down menu.

[0088] The build task configuration module serves as the system's front-end interface, receiving user requests through a parameterized build process. Users select the set of software components to be built via checkboxes and explicitly specify the build type via drop-down menus or single-line text boxes, thus achieving standardized and structured input of build requirements.

[0089] The software version management module serves as the system's information hub, responsible for maintaining and managing all version and configuration information. It utilizes the HTML Publisher plugin to generate a visual interface that intuitively displays and allows editing of key information such as version type, build number, and software components, providing users with a clear global view and operational entry point.

[0090] As the core of the system's execution, the integrated build engine intelligently schedules requests based on the request parameters parsed by the build task configuration module and the configuration information provided by the software version management module. It issues build instructions to the corresponding heterogeneous build nodes and strictly controls the order and status of the entire build process (including code retrieval, static analysis, compilation and packaging).

[0091] User interactions on the front-end interface (checking, selecting, inputting) generate structured build parameters. These parameters drive the build task configuration module to generate tasks. After obtaining the tasks, the integrated build engine retrieves the necessary version rules and environment configurations from the software version management module, thereby precisely driving the entire automation chain.

[0092] The effects of the above technical solution are as follows: By providing standardized form elements such as checkboxes and drop-down menus, operations that originally required complex command lines or configuration file modifications are simplified into intuitive graphical interface selections, significantly reducing the user's operational threshold and technical burden. At the same time, by restricting input options, the system avoids construction failures caused by incorrect parameter formats, spelling errors, or illegal combinations of selections from the source, greatly improving the accuracy and reliability of the operation.

[0093] By dividing the server into three clearly defined modules—build task configuration (front-end interaction), software version management (information hub), and integrated build engine (execution control)—high cohesion and low coupling of system functions are achieved. This allows each module to be developed, maintained, and upgraded independently (e.g., optimizing the interface does not affect the engine logic), enhancing the system's scalability and maintainability. At the same time, the modules work together through standard interfaces, ensuring the efficiency and stability of the overall process.

[0094] The software version management module generates a visual interface that centrally presents all version information and build configurations, providing unprecedented transparency and enabling users and administrators to quickly grasp the system status. Combined with the centralized control of the integrated build engine, it achieves "one-stop" management and control of distributed, heterogeneous build nodes and complex build processes, significantly improving operational efficiency and the manageability of the entire build system.

[0095] In one possible implementation, the integrated build engine is further configured with a static analysis strategy dynamic adjustment module, used to optimize the defect judgment criteria of static code analysis based on correlation analysis of historical build data; the correlation analysis includes: The statistical correlation coefficient between the total number of static code analysis warnings in historical data and the number of critical defects found during the testing phase is calculated. The critical defects are those that affect the core functions of the proton therapy system (such as dose control and equipment linkage). When the correlation coefficient is consistently higher than a preset confidence threshold (e.g., 0.7) for a specific build type (RELEASE_BUILD / TEST_BUILD / DAILY_BUILD) for more than N build cycles (N≥3), the static analysis strategy dynamic adjustment module automatically raises the static code analysis defect level threshold for that build type, upgrading defects originally judged as low-level warnings to blocking errors, thereby strengthening the security control of high-risk build types.

[0096] The effects of the above technical solution are as follows: Traditional static analysis tools typically have fixed rules and thresholds that cannot be self-optimized as the project progresses and code quality changes. This solution enables quality control standards to be automatically adjusted based on actual quality feedback data, giving the build system the ability to learn and evolve, and continuously maintaining the most effective quality control state.

[0097] By implementing differentiated, data-validated, and rigorous strategies for different build types (such as official and beta versions), the highest quality control resources can be focused on the highest-risk and most demanding delivery stages (such as RELEASE_BUILD). This is equivalent to automatically adding an enhanced safety net to critical releases, intercepting potential risks that have been proven to be highly correlated with serious defects at the code level in advance, greatly reducing the possibility of bringing fatal defects into the clinical treatment stage.

[0098] By introducing quantitative indicators such as statistical correlation coefficients, the process of adjusting quality control strategies, which originally relied on expert experience, is transformed into a data-driven and objective engineering decision-making process. This avoids the subjectivity and lag of human judgment, ensuring that every strategy adjustment is based on evidence and improving the credibility and authority of the quality control system.

[0099] This mechanism can intelligently identify which warnings are truly important and enforce strict control only at the right time (for specific build types), avoiding the efficiency loss caused by indiscriminately enabling all strict rules in all builds. This allows development teams to focus on fixing code issues that truly affect the core functionality of the system, thereby achieving the best balance between quality and development efficiency.

[0100] In one possible implementation, the static analysis strategy dynamic adjustment module further integrates a machine learning prediction submodule, used to upgrade the risk management of static code analysis from ex-post adjustment based on historical rules to ex-ante prevention based on prediction; the machine learning prediction submodule is configured as follows: The prediction model is trained using historical build data, which includes the original results of static code analysis (the number, distribution, and module relationships of various defects) and records of critical defects in the corresponding version during the testing phase (critical defects are defined as defects that may lead to treatment interruption or dosage error). The prediction model takes the static code analysis results of the current build as input features and outputs the predicted probability of critical defects occurring in the current build during the testing phase. The dynamic decision logic of the integrated build engine is updated to: if the predicted probability exceeds a preset risk threshold (set for proton therapy systems, such as ≥5%), then even if the original results of static code analysis meet the existing standards, the current build is still marked as a failure and needs to be repaired and retried.

[0101] In a preferred implementation, the prediction model is a supervised learning model whose core task is to map the currently constructed static code analysis results to a risk probability. Given that the input features (number of various defects, etc.) are mostly structured numerical data, and considering the potential requirements of medical software for model interpretability, the prediction model can choose, but is not limited to, one or more of the following model architectures, including logistic regression models, gradient boosting decision tree models (e.g., XGBoost, LightGBM), and random forest models.

[0102] The original results of the currently constructed static code analysis are used as the feature vector. This vector specifically includes: Defect quantity characteristics: the total number of critical defects, serious defects, and general warnings.

[0103] Defect distribution characteristics: Defect density (number of defects per thousand lines of code) within each software module (such as the treatment control module and the image acquisition module).

[0104] Defect type characteristics: The number of times a specific security rule (such as CWE-78 OS command injection, CWE-120 buffer overflow) is violated.

[0105] Historical trend characteristics: The rate of change of the number of various types of defects in this build compared with the most recent N builds.

[0106] The model outputs a scalar between 0 and 1, which is the predicted probability that a critical defect will occur during the testing phase of this build.

[0107] The training of the prediction model is a typical supervised learning process that relies on high-quality historical construction data. The specific steps are as follows: From the system's historical records, collect K historical construct samples (e.g., K ≥ 1000) to form the training dataset. Each sample is a data pair: Input: The original results of static code analysis of a single historical construction (i.e., the input feature vector mentioned above).

[0108] The label section represents the actual quality performance corresponding to this historical build, and is a binary label (0 or 1). If this version is found to have at least one critical defect (defined as a defect that may lead to treatment interruption or dosage error) during the testing phase, it is labeled as 1; otherwise, it is labeled as 0.

[0109] Preprocess the training dataset to ensure training quality: Feature standardization: Numerical features (such as the number of defects) are standardized (e.g., Z-score standardization) to make their mean 0 and standard deviation 1, so as to eliminate the influence of the units on the model.

[0110] Missing value handling: For any missing data, appropriate methods should be used to handle it, such as filling with the median or ignoring the sample.

[0111] Data balancing: If the proportion of positive samples (constructed with label 1) in the dataset is too small, oversampling (such as the SMOTE algorithm) or undersampling techniques are used to balance the class distribution and prevent the model from being biased towards the majority class.

[0112] The preprocessed training dataset is randomly divided into training and validation sets according to a preset ratio (such as 7:3 or 8:2).

[0113] Using training set data, with the goal of minimizing prediction error (such as binary cross-entropy loss), the parameters of the model are fitted using optimization algorithms (such as gradient descent).

[0114] The performance of the trained model is evaluated using a validation set that was not used in the training. Evaluation metrics include, but are not limited to, accuracy, precision, recall, and AUC to ensure that the model has good generalization ability and has not simply memorized the training data.

[0115] Based on the prediction results of the validation set, a PR curve or ROC curve is plotted, and combined with the business requirements for risk tolerance of the proton therapy system, a final preset risk threshold (e.g., ≥5%) is determined. This threshold is used to transform the continuous probability output of the model into a pass / fail binary decision in the production environment.

[0116] The trained and validated model, along with its preprocessing parameters and decision thresholds, is packaged and integrated into the unified construction engine. In each construction process, the engine calls the model to perform real-time inference on the current static analysis results and executes dynamic decisions based on the comparison between the output probability and the risk threshold.

[0117] The effects of the above technical solution are as follows: Traditional quality control relies on retrospective adjustments based on statistical analysis of past issues. This solution, through real-time analysis of current code characteristics, proactively predicts potential critical defects that have not yet occurred, establishing a truly proactive prevention mechanism. This moves the quality control checkpoint forward to the build stage, rather than waiting for problems to be discovered during testing. By specifically defining critical defects that may lead to treatment interruption or dosage errors as training targets, the model closely aligns with the clinical safety requirements of proton therapy systems. The machine learning model can uncover complex risk correlation patterns that are difficult for human experts to detect from multi-dimensional features (defect quantity, distribution, module relationships). Even if individual indicators meet existing standards, the model can still identify systemic risks based on feature combinations, achieving a more comprehensive quality assessment. Replacing the traditional binary pass / fail judgment with continuous probability values ​​provides richer evaluation dimensions for build quality. This effectively solves the dilemma of false positives leading to build failures and missed defects in traditional static analysis, optimizing development efficiency while ensuring safety.

[0118] In one possible implementation, the build management server further includes a strategy self-optimization module for fully automated evolution of static analysis strategy adjustment, build quality feedback, and strategy iterative optimization; the strategy self-optimization closed-loop module is configured as follows: Maintain a quality strategy and result mapping table to record the defect escape rate (i.e., the proportion of serious defects not detected by static analysis but discovered during testing) of the corresponding build version after each adjustment of defect level thresholds or prediction model parameters; by analyzing the mapping table, automatically learn the effectiveness of the adjustment strategy: If, after raising the judgment level of a specific defect by a preset level (e.g., from warning to error), the defect escape rate decreases by more than a first preset proportion (e.g., 30%) in the subsequent M (e.g., M=5) build cycles, then the strategy is deemed effective and retained.

[0119] If, after the above adjustments, the average defect escape rate of the subsequent M build cycles fluctuates within a preset range (e.g., within ±10%) compared to the average of the previous M cycles, the strategy is deemed invalid; or, if the average completion time of the build task is extended by more than a second preset percentage (e.g., 20%), the build efficiency is deemed substandard. When either of the above situations occurs, the strategy self-optimization closed-loop module automatically triggers at least one of the following enhancement optimization operations: The scope of the defect level escalation strategy will be expanded from the current single defect category (such as critical security vulnerabilities) to cover multiple related defect categories (such as simultaneously including critical security vulnerabilities and major performance defects). Call the retraining interface of the machine learning prediction submodule, use the latest dataset containing the data of this failure strategy, and recalculate and update the feature weights of the model with the core optimization goal of reducing the defect escape rate. The strategy iteration process must meet the compliance requirements of the proton therapy system, and the adjustment records, quantitative basis and decision-making logic will be automatically synchronized to the version traceability system as audit evidence for medical software lifecycle management.

[0120] The effects of the above technical solution are as follows: Through clearly defined quantitative standards (e.g., a 30% decrease in escape rate is considered effective, and a 20% increase in build time is considered inefficient), the system can intelligently judge the cost-effectiveness of strategy adjustments. When a single strategy fails, it automatically triggers targeted reinforcement measures (e.g., expanding the control scope or optimizing the prediction model) to ensure that the quality control intensity is dynamically adapted to the risk level. All strategy adjustment decisions are based on statistical data from M build cycles, avoiding accidental decisions based on the results of a single build. By using preset quantitative thresholds (±10% fluctuation range, 20% efficiency threshold), the system achieves a completely objective determination of strategy effectiveness, eliminating inconsistencies in human experience judgments. When a strategy is ineffective, it provides two reinforcement paths: horizontal expansion (expanding the range of defect categories) and vertical deepening (optimizing the prediction model). The system can select the most suitable optimization direction according to the specific scenario, either by expanding the control scope to strengthen coverage or by optimizing the model to improve accuracy. All strategy adjustment records, quantitative basis, and decision logic are automatically synchronized to the version traceability system, forming a complete and tamper-proof audit evidence chain. This provides a complete quality control process record that is machine-readable and manually verifiable for the lifecycle management of proton therapy system software, greatly simplifying the compliance certification process.

[0121] See appendix Figure 2 Example 2: This example provides an automated software construction method for proton therapy systems, which can be implemented using the automated software construction system for proton therapy systems described in Example 1. The method includes: The system receives build requests submitted by users through a build management server, and the build requests include at least a set of software components to be built. In response to the build request, build instructions are issued to multiple heterogeneous build nodes through the build management server; The build instructions drive the build nodes to perform static code analysis on the source code of the software component set, and compile and package the code after the analysis is successful.

[0122] In one possible implementation, the build management server is a Jenkins-based platform and communicates with the build nodes and transfers files via the SSH protocol; the build management server is deployed on a Windows operating system platform; the build nodes include at least build nodes running on Linux systems and build nodes running on Windows systems.

[0123] In one possible implementation, the build node running on a Linux system includes at least one Red Hat virtual machine, which is pre-configured with SSH service and has port 22 open, and connects to the build management server via key authentication.

[0124] In one possible implementation, the build node includes multiple virtual machines, each pre-configured with a dedicated build user and permissions, and authenticated with the build management server via an SSH key pair; wherein the build management server verifies the communication status with the build node by testing the connection.

[0125] In one possible implementation, the build instruction is configured to drive the build node to complete the static code analysis before performing the compilation operation; if the analysis does not detect defects of a preset level, the compilation and packaging operations continue; otherwise, the build process is interrupted and the current build is marked as a failure; wherein, the static code analysis includes code security scanning and compliance checks to identify security vulnerabilities and violations of programming standards.

[0126] In one possible implementation, the build request further includes a build type; the build management server selects and issues instructions to the corresponding heterogeneous build nodes based on the software component set and the build type.

[0127] In one possible implementation, the step of selecting and issuing instructions to the corresponding heterogeneous build nodes based on the software component set and build type includes: Maintain the capability profile of the building node, which includes the node's static configuration information and dynamic operating indicators; Based on the construction type, determine the resource requirement preferences for this construction task; Based on the resource demand preferences, a weighted algorithm is used to calculate the fit score between each candidate node and the current task. The node with the highest fitness score is selected as the target node.

[0128] The static configuration information includes the number of CPU cores, memory capacity, and operating system version; The dynamic performance metrics include current CPU load, available memory, and historical build success rate.

[0129] In one possible implementation, determining the resource requirement preferences for this construction task based on the construction type includes: When the build type is RELEASE_BUILD, the resource requirement preference is set to reliability first, and the historical build success rate metric is assigned the highest weight in the weighted algorithm. When the build type is DAILY_BUILD, the resource requirement preference is set to efficiency first, and the current CPU load and available memory metrics are assigned the highest weight in the weighted algorithm.

[0130] In one possible implementation, the weighted algorithm also considers the historical construction time of the node for the set of software components when calculating the fitness score.

[0131] In one possible implementation, the method further includes the step of: After the build task is completed, update the dynamic performance metrics of the corresponding nodes based on the actual results of the build.

[0132] In one possible implementation, the method further includes: Upon responding to the build request, a version identifier is automatically generated or updated; and the build node is driven to create a version tag in the code repository based on the version identifier; wherein, the version identifier is automatically generated or updated through a version management script, which iterates the version number according to the build type and preset coding rules.

[0133] In one possible implementation, the build instruction drives the build node to perform the following operations in sequence: obtain the source code of the specified component from the code repository, then perform the static code analysis, and after the analysis is successful, perform compilation and packaging operations.

[0134] In one possible implementation, the software components in the software component set include at least one of a treatment control module, an image acquisition module, an accelerator control module, a dose measurement control module, and a radio frequency control module; wherein each software component corresponds to an independent code repository branch, and the build instruction pulls the source code of the corresponding branch according to the user's selection.

[0135] In one possible implementation, the build management server includes a software version management module, a build task configuration module, and an integrated build engine; the method further includes: The software version management module maintains and manages the software version information and build configuration information. The build request is received through the build task configuration module; The integrated build engine executes the issuance of build instructions and controls the process.

[0136] In one possible implementation, the build task configuration module receives user requests via a parameterized build format, wherein the set of software components is provided as checkboxes, and the build type is specified via a single-line text box or a drop-down menu.

[0137] In one possible implementation, the software version management module generates a visual interface through an HTML Publisher plugin to display and edit version types, build numbers, and software components; the build task configuration module receives user requests through parameterized builds, wherein the set of software components is provided in the form of checkboxes, and the build type is specified through a drop-down menu or a single-line text box.

[0138] In one possible implementation, the method further includes receiving the results of the static code analysis and displaying the results to the user in real time on a visualization interface; wherein the results include a list of defects, severity levels, and remediation suggestions, and when the analysis fails, the build process is interrupted and the reason for the failure is highlighted.

[0139] In one possible implementation, the method further includes: After the build is completed, the build status and results are displayed in real time on the visualization interface, and an access interface for detailed logs is provided. The build status includes success, failure, or interruption, and users can click on the interface to view compilation errors, test case failures, or static code analysis details.

[0140] In one possible implementation, the version management script automatically selects the iteration rules for version numbers based on the build type; wherein, the official build adds a major version number, the test build adds a minor version number, and the development build adds a build number, and the version numbers follow the semantic versioning specification.

[0141] In one possible implementation, the method further includes: After packaging, the build artifacts are transmitted to a pre-configured file server via the SCP protocol through the build node; the build artifacts include binary files, dynamic libraries and configuration files, and the file server path is automatically generated based on the version identifier.

[0142] In one possible implementation, the method further includes: Based on the set of software components selected by the user, the build management server dynamically coordinates multiple heterogeneous build nodes to perform code updates, static code analysis, and compilation operations in parallel; the dependencies between build nodes are managed through a preset process to ensure the correctness of the build order.

[0143] In one possible implementation, the method further includes: The static code analysis includes a mandatory scan of C / C++ code to detect memory leaks, buffer overflows, and pointer errors. The analysis tools are integrated into the build node, and the analysis threshold is adjusted according to the build type, with the official build using a more stringent threshold.

[0144] In one possible implementation, the method further includes a step of performing correlation analysis based on historical build data to optimize the defect judgment criteria of static code analysis; The association analysis includes: Calculate the statistical correlation coefficient between the total number of static code analysis warnings in historical data and the number of critical defects found during the testing phase, wherein the critical defects are those that affect the core functions of the proton therapy system; When the correlation coefficient is consistently higher than the preset threshold for a specific build type and exceeds N build cycles, the static code analysis defect level threshold for that build type is automatically raised, and defects originally judged as low-level warnings are upgraded to blocking errors.

[0145] In one possible implementation, the method further includes a machine learning-based predictive quality control step: The prediction model is trained using historical data, which includes the raw results of static code analysis and records of key defects in the corresponding version during the testing phase. Using the static code analysis results of the current build as input, the prediction model outputs the predicted probability of a critical defect occurring during the testing phase of this build; If the predicted probability exceeds the preset risk threshold set for the proton therapy system, the current construction will be marked as a failure even if the original static code analysis results meet the existing standards.

[0146] In one possible implementation, the method further includes a strategy self-optimization step to achieve fully automated evolution of static analysis strategy adjustment, quality feedback construction, and iterative strategy optimization, including: Maintain the quality strategy and result mapping table, and record the defect escape rate of the corresponding build version after each adjustment of the defect level threshold or prediction model parameters; By analyzing the mapping table, the effectiveness of the adjustment strategy is automatically learned: If, after raising the judgment level of a specific defect by a preset level, the defect escape rate decreases by more than a first preset proportion in the subsequent M build cycles, then the strategy is deemed effective and retained. If, after the above adjustments, the average defect escape rate over the subsequent M build cycles fluctuates within a preset range compared to the average of the M cycles before the adjustment, or if the average completion time of the build task is extended by more than a second preset proportion, then at least one enhancement and optimization operation will be automatically triggered, including: Expand the scope of static analysis, extending the application of defect level escalation strategies from the current single defect category to cover multiple related defect categories; or Initiate the reinforcement learning process for the model and retrain the prediction model using the latest dataset containing the data from the failed policy. The strategy iteration process must meet the compliance requirements of the proton therapy system, and all adjustment records, quantitative basis and decision-making logic are automatically synchronized to the version traceability system.

[0147] See attached document Figure 3 As a specific implementation method, a software automation construction method for proton therapy systems is implemented through Shell scripts: An automated software build system for proton therapy systems; the system includes a Jenkins server deployed on a Windows operating system platform as the build management server, and at least one Red Hat virtual machine pre-configured with SSH service and key authentication as a heterogeneous build node. Specifically, it includes the following steps: S101: Environment Preparation and Task Parameter Reception Users submit build requests via parameterized builds through the Jenkins platform's visual interface. These requests include: a set of software components selected via checkboxes (e.g., a treatment control module), a build type specified via a dropdown menu (e.g., RELEASE_BUILD), and current version information (e.g., 3.0.0 R6).

[0148] S102: Version identifier automatically generated In response to a build request, the Jenkins server invokes the shell script buildPara.sh, which is pre-stored in the Red Hat virtual machine's / home / mevion / Source / scanning / directory. Based on the passed parameters (such as Build_Type=Release, current_version=3.0.0, build_num=6), the script automatically calculates and outputs a new version identifier (e.g., "3.0.0 R6") according to preset encoding rules.

[0149] S103: Source Code Acquisition and Mandatory Static Code Analysis Jenkins drives Red Hat build nodes via the SSH protocol, performing the following operations: Use Git to pull the latest source code of the corresponding branch of the control module from the code repository to the / home / mevion / Source / scanning / directory.

[0150] Perform code security scanning and compliance checks on the acquired source code. This step serves as a quality gate; if the analysis fails (a pre-defined level of defect is detected), the build process is immediately interrupted and the build is marked as failed.

[0151] S104: Code Tag Creation and Compilation / Packaging After the static code analysis passes, the build node continues execution: Based on the version identifier "3.0.0 R6" generated by S102, execute the command "git tag -a 3.0.0 R6" in the code repository to create a version tag and push it to the remote repository.

[0152] Execute the compilation command to generate the software installation package for the control module.

[0153] S105: Feedback on Construction Results After the build is complete, the installation package is transferred to the file server via the SCP plugin. The Jenkins platform displays the final build result (build successful or failed) on a visual interface and allows users to view detailed logs, including static code analysis reports.

[0154] The working principle and effect of the above technical solution are the same as those of the software automated construction system for proton therapy system in Example 1, and will not be repeated here.

[0155] This invention also provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the functions of the system described in Embodiment 1 of this invention or the steps of the method described in Embodiment 2 of this invention.

[0156] This invention also provides a computer-readable storage medium for storing a computer program. When the computer program is executed, it implements the functions of the system described in Embodiment 1 of this invention or the steps of the method described in Embodiment 2 of this invention. The specific implementation method is consistent with the implementation method and the technical effects achieved in the above method embodiments, and some contents will not be repeated.

[0157] In this invention, a readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. The program product can take the form of any combination of one or more readable media. A readable medium can be a readable signal medium or a readable storage medium. A readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof.

[0158] Computer-readable storage media may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The readable storage medium may also be any readable medium capable of sending, propagating, or transmitting a program for use by or in conjunction with an instruction execution system, apparatus, or device. The program code contained on the readable storage medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, or any suitable combination thereof. Program code for performing operations of the present invention may be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, as well as conventional procedural programming languages ​​such as C or similar programming languages. The program code may be executed entirely on a user computing device, partially on an associated device, as a standalone software package, partially on a user computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing devices can be connected to user computing devices via any type of network, including local area networks (LANs) or wide area networks (WANs), or they can be connected to external computing devices (e.g., via the Internet using an Internet service provider).

[0159] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the invention without departing from the principles and spirit of the invention, and all such changes should fall within the protection scope of the claims of the present invention.

Claims

1. A software automation construction system for proton therapy systems, characterized in that, The system includes: Build a management server and deploy it on the first operating system platform; Multiple heterogeneous build nodes are communicatively connected to the build management server; The build management server is configured as follows: Receive a build request submitted by a user, the build request including at least a set of software components to be built; In response to the build request, a build instruction is issued to the corresponding heterogeneous build node; The build instruction drives the build node to perform static code analysis on the source code of the software component set, and compiles and packages the code after the analysis is successful.

2. The software automated construction system according to claim 1, characterized in that, The build management server is a Jenkins-based platform and communicates and transfers files with the build nodes via the SSH protocol; the first operating system platform is a Windows operating system platform; the heterogeneous build nodes include at least build nodes running Linux and build nodes running Windows.

3. The software automated construction system according to claim 2, characterized in that, The build node running on the Linux system includes at least one Red Hat virtual machine, which is pre-configured with SSH service and has port 22 open, and connects to the build management server via key authentication.

4. The software automated construction system according to claim 1, characterized in that, The build node includes multiple virtual machines, each virtual machine is pre-configured with a dedicated build user and permissions, and is authenticated with the build management server via an SSH key pair; wherein, the build management server verifies the communication status with the build node by testing the connection.

5. The software automated construction system according to claim 1, characterized in that, The build instructions are configured to drive the build node to complete the static code analysis before performing the compilation operation; if the analysis does not detect defects of a preset level, the compilation and packaging operations continue; otherwise, the build process is interrupted and the current build is marked as a failure; wherein, the static code analysis includes code security scanning and compliance checks to identify security vulnerabilities and violations of programming standards.

6. The software automated construction system according to claim 1, characterized in that, The build request also includes a build type; the build management server is configured to select and issue instructions to the corresponding heterogeneous build nodes based on the software component set and the build type.

7. The software automated construction system according to claim 1, characterized in that, The build management server is also configured to: automatically generate or update a version identifier in response to the build request; and drive the build node to create a version tag in the code repository based on the version identifier; wherein the version identifier is automatically generated or updated through a version management script, which iterates the version number according to the build type and preset coding rules.

8. The software automated construction system according to claim 1, characterized in that, The build instructions are designed to drive the build node to perform the following operations in sequence: first, obtain the source code of the specified component from the code repository, then perform the static code analysis, and after the analysis is successful, perform the compilation and packaging operations.

9. The software automated construction system according to claim 1, characterized in that, The software components in the software component set include at least one of the following: a treatment control module, an image acquisition module, an accelerator control module, a dose measurement control module, and a radio frequency control module; wherein, each software component corresponds to an independent code repository branch, and the build instruction pulls the source code of the corresponding branch according to the user's selection.

10. The software automated construction system according to claim 1, characterized in that, The build management server includes: The software version management module is used to maintain and manage the version information and build configuration information of the software. A task configuration module is built to receive the build request; An integrated build engine is used to execute the issuance of build instructions and control the process.

11. The software automated construction system according to claim 10, characterized in that, The software version management module generates a visual interface through the HTML Publisher plugin, which is used to display and edit version types, build numbers, and software components; the build task configuration module receives user requests through parameterized builds, wherein the software component set is provided in the form of checkboxes, and the build type is specified through drop-down menus or single-line text boxes.

12. The software automated construction system according to claim 10, characterized in that, The build task configuration module receives user requests through a parameterized build format, wherein the software component set is provided in the form of checkboxes, and the build type is specified through a single-line text box or a drop-down menu.

13. A method for automated software construction for proton therapy systems, characterized in that: The method includes: The system receives build requests submitted by users through a build management server, and the build requests include at least a set of software components to be built. In response to the build request, build instructions are issued to heterogeneous build nodes through the build management server; The build instructions drive the build nodes to perform static code analysis on the source code of the software component set, and compile and package the code after the analysis is successful.

14. An electronic device, characterized in that, The electronic device includes a memory and a processor. The memory stores a computer program, and when the processor executes the computer program, it performs the functions of the system according to any one of claims 1-12 or implements the steps of the method according to claim 13.

15. A computer-readable storage medium, characterized in that, The storage medium stores computer instructions, and when the computer reads the computer instructions, the computer performs the function of the system according to any one of claims 1-12.

Images