A ship design scheme generation method and electronic equipment

Abstract

The application provides a ship design scheme generation method, including the following steps: obtaining a ship MBSE model library, and converting it into a ship design knowledge graph; generating a standardized description for the knowledge graph node and vectorizing it to form a node vector library; constructing a hierarchical semantic index through hierarchical clustering, and establishing a mapping; performing semantic enhancement and structured analysis on the natural language demand through a large language model; performing hierarchical retrieval from top to bottom based on the hierarchical index to obtain candidate design data; performing constraint pruning on the candidate design data; synthesizing a scheme based on the qualified data and automatically generating an MBSE model; and outputting delivery items such as the scheme, the model, a traceability matrix, and a review report. The scheme provided by the application can realize rapid and traceable conversion of natural language multi-source demand into a structured ship overall scheme and an MBSE model, guarantee that the scheme meets regulatory constraints, parameters are consistent, and engineering is achievable, and improve design efficiency, reduce iteration cost and review risk.

Description

Technical Field

[0001] This invention relates to the field of marine engineering, and in particular to a method for generating ship design schemes and an electronic device. Background Technology

[0002] Ships, especially specialized and commercial vessels with complex mission profiles, multiple regulatory constraints, and tightly coupled subsystems, require extensive iterative trade-offs across multiple disciplines during the conceptual and preliminary design phases, including overall dimensions, line-form resistance, stability structure, power and electricity, outfitting layout, and mission systems. Design knowledge and experience are scattered across historical project documents, classification society rules, international maritime conventions, calculation tables, and expert experience, resulting in high costs for knowledge reuse, difficulty in tracing decision-making basis, and long design iteration cycles.

[0003] Model-Based Systems Engineering (MBSE) uses formal models throughout the entire system lifecycle, which can improve cross-disciplinary collaboration, requirement tracing, and change impact analysis capabilities. However, existing ship MBSE model libraries are generally flat storage, lacking a semantically oriented hierarchical index structure, relying on manual labeling and experience-based retrieval, resulting in low efficiency of model reuse across projects.

[0004] Large Language Models (LLMs) have significant advantages in natural language requirement understanding, information extraction, and knowledge organization. However, in safety-critical and regulatory-intensive fields such as shipbuilding engineering, pure large language model generation suffers from serious illusion problems. The output solutions may have defects such as parameter conflicts, regulatory inconsistencies, interface mismatches, and lack of engineering implementation, requiring extensive manual review.

[0005] Therefore, the concept / preliminary design phase of ships urgently needs an intelligent generation method that deeply integrates MBSE structured models with large language models, and has offline knowledge structuring, online hierarchical retrieval, constraint verification, automatic scheme synthesis, and full-link traceability, in order to solve the technical problem of difficulty in balancing speed, reliability, and traceability. Summary of the Invention

[0006] The purpose of this invention is to overcome the shortcomings of related technologies, such as reliance on human experience in early ship design, unreliable LLM generation, low efficiency of MBSE model reuse, and difficulty in automatically verifying regulatory constraints. This invention provides an intelligent generation method for ship design schemes driven by MBSE and large language models, which enables rapid and traceable conversion from multi-source natural language requirements to structured overall ship schemes and MBSE models. This ensures that the schemes meet regulatory constraints, have consistent parameters, and are engineering-feasible, thereby improving design efficiency and reducing iteration costs and review risks.

[0007] This application provides a method for generating ship design schemes, comprising the following steps: acquiring a ship MBSE model library and converting the ship MBSE model library into a ship design knowledge graph; generating standardized natural language descriptions for nodes in the ship design knowledge graph and vectorizing the natural language descriptions to obtain a node vector library; performing hierarchical clustering based on the node vector library to construct a hierarchical semantic index; acquiring user-input natural language ship design requirements, and using a large language model to perform semantic enhancement and structured parsing on the natural language ship design requirements to obtain structured requirement data; performing top-down hierarchical retrieval on the hierarchical semantic index based on the structured requirement data to obtain a candidate design data set; performing constraint pruning on the candidate design data set to obtain target design data that meets the constraint conditions; and synthesizing ship design schemes based on the target design data to generate ship design scheme deliverables.

[0008] In one embodiment, before acquiring the ship MBSE model library, the method further includes constructing the ship MBSE model library. Constructing the ship MBSE model library includes: establishing a ship requirements model that includes mappings of ship missions, operational concepts, and regulatory clauses; decomposing the ship missions into ship functions and establishing a functional architecture model, wherein the ship functions include navigation functions, positioning functions, transport / operation functions, energy management functions, safety functions, and fire prevention functions; allocating the ship functions to ship subsystems and key equipment / modules and establishing a physical architecture model, wherein the ship subsystems include hull / structure subsystems, propulsion and power subsystems, power generation / distribution subsystems, outfitting subsystems, and mission equipment subsystems; establishing a parameter / analysis model that includes key parameters and calculation relationships, wherein the key parameters include weight center of gravity, power balance, propulsion performance, and stability; recording the regulatory / rule clauses to be verified and the verification methods, and establishing a verification use case model.

[0009] In one embodiment, converting the ship MBSE model library into a ship design knowledge graph includes: reading the model serialization file of the ship MBSE model library and parsing it into an internal object graph, wherein the ship MBSE model library is built using SysML language; determining the nodes in the knowledge graph based on the internal object graph, wherein the types of the nodes include requirement nodes, scenario nodes, function nodes, subsystem nodes, equipment / module nodes, parameter nodes, rule clause nodes, and verification object nodes; establishing the association relationships between the nodes to form edges in the knowledge graph, wherein the types of the association relationships include derived requirements, satisfaction, allocation, composition, interface, constraint, verification, and traceability reference; and constructing the knowledge graph by attaching regulations / rules as clause nodes based on the nodes and edges in the knowledge graph.

[0010] In one embodiment, the step of vectorizing the natural language description to obtain a node vector library includes: using the BERT model to map the natural language description into vectors to form a node vector library.

[0011] In one embodiment, the step of performing hierarchical clustering processing based on the node vector library to construct a hierarchical semantic index includes: performing hierarchical clustering on the node vector library using the HDBSCAN algorithm to generate a cluster tree with a multi-layer cluster structure, wherein the cluster tree includes multiple cluster nodes, and each cluster node represents a node vector of the same category; storing the ship design knowledge graph and the cluster nodes together, and constructing a mapping table between the cluster nodes and the nodes in the ship design knowledge graph.

[0012] In one embodiment, the step of using a large language model to perform semantic enhancement and structured parsing of the natural language ship design requirements includes: using a large language model to transform the natural language ship design requirements into a requirement vector-requirement slot table, wherein the requirement slots include task profile, environment and boundary, strong constraints, objective function, and permissible trade-offs; performing semantic completion on the implicit requirements in the natural language ship design requirements, and marking the completed content as inference terms.

[0013] In one embodiment, the step of performing a top-down hierarchical retrieval on the hierarchical semantic index based on the structured requirement data to obtain a candidate design data set includes: calculating the similarity between the structured requirement data and the top-level cluster nodes of the hierarchical semantic index, selecting the TopK similarity cluster nodes as candidate top-level cluster nodes; expanding each candidate top-level cluster node downwards in parallel, and retrieving matching nodes in the ship design knowledge graph layer by layer according to the mapping table to form a candidate design data set.

[0014] In one embodiment, the process of synthesizing ship design schemes based on the target design data and generating ship design scheme deliverables includes: generating ship MBSE artifacts based on the target design data; performing engineering feasibility verification and interpretive output on the ship MBSE artifacts to obtain a ship overall scheme report, SysML model files / model service links, a requirement traceability matrix, and a verification report.

[0015] This application also provides an electronic device, which includes: a processor; and a memory for storing processor-executable instructions; wherein the processor is configured to execute the above-described ship design scheme generation method.

[0016] The method provided in the above embodiments of this application realizes the automated generation of ship design schemes from natural language requirements, shortening the original conceptual design iteration from several days to several weeks to hours, significantly improving design efficiency; through the triple mechanism of knowledge graph + hierarchical semantic index + constraint pruning, it greatly reduces the illusion of LLM and improves engineering usability. Attached Figure Description

[0017] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly described below.

[0018] Figure 1 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application; Figure 2 This is a flowchart illustrating a method for generating a ship design scheme according to an embodiment of this application; Figure 3 This is a flowchart illustrating another method for generating ship design schemes according to an embodiment of this application. Detailed Implementation

[0019] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0020] Similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, terms such as "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0021] Ships (especially those designed for complex mission profiles, subject to numerous regulatory constraints, and with highly coupled subsystems) require repeated trade-offs among multiple disciplines, including overall dimensions, hull form / resistance propulsion, stability / structure, power / electricity, outfitting and layout, and mission systems, in their early stages, and the design process is significantly iterative. Literature descriptions of typical ship development processes usually divide them into stages such as conceptual design, preliminary design, contract design, and detailed design, with multiple iterations required in the conceptual / preliminary stage to gradually converge on a single design.

[0022] At the basic design level, it is necessary to determine the key characteristics that affect cost and performance (such as main dimensions, hull form / line, power and engine room layout, main structure, etc.). This kind of knowledge and experience is often scattered in historical project documents, specification clauses, calculation tables and expert experience, resulting in high cost of knowledge reuse and difficulty in tracing the basis of decision-making.

[0023] From a systems engineering perspective, MBSE is widely recognized as being able to use "formal models" to navigate the entire lifecycle of a system, contrasting with traditional document-centric approaches and making cross-team collaboration, change impact analysis, and requirements tracking more controllable. For example, the International Council on Systems Engineering's vision for systems engineering explicitly emphasizes that future systems engineering will be more model-based, combining AI / automation to improve the efficiency of reuse and trade-off analysis.

[0024] In the maritime industry, regulations and norms are characterized by "strong external constraints." For example, the International Convention for the Safety of Life at Sea (SOLAS) of the International Maritime Organization aims to establish minimum safety standards for ship construction, equipment, and operation, and to demonstrate compliance through a certification system. These requirements directly impact layout, equipment selection, and system redundancy strategies. Simultaneously, classification society rules (such as the classification rules and standards provided by DNV (Det Norske Veritas)) impose procedural and technical requirements on structures, equipment, and validation documentation, further increasing the need for structured management of design constraints.

[0025] While LLM (Limited Learning Model) has advantages in requirements understanding, information extraction, and knowledge organization, research also points out that LLM carries the risk of generating illusions that are "seemingly reasonable but not realistic." In engineering and safety-related fields, it is necessary to introduce retrieval enhancement, verifiable evidence, and constraint verification mechanisms to improve credibility. This creates a typical contradiction: early-stage ship design requires intelligent assistance that is "rapid, multi-solution, interpretable, and traceable," while relying solely on manual experience bases or simply on LLM-generated data makes it difficult to simultaneously meet reliability and engineering usability requirements.

[0026] In related technologies, there are generally several routes from natural language requirements to design solution generation, as detailed below: The first approach is the LLM direct reasoning generation solution (which can utilize chain-thinking hints). This route often improves the performance of complex reasoning by adding intermediate reasoning steps to the hints, but it does not inherently rely on external structured knowledge or verifiable engineering constraint libraries. In engineering design scenarios, this means that the output component selection, parameter consistency, and regulatory compliance require additional manual review; otherwise, a solution that is "fluently described but unimplementable" may result.

[0027] The second approach is knowledge retrieval-enhanced generation based on RAG (Retrieval-Enhanced Generation) / GraphRAG (Graph Retrieval-Enhanced Generation). The original RAG paradigm uses externally retrieved evidence to support generation, thereby improving the accuracy and updability of knowledge-intensive tasks. GraphRAG further extracts unstructured corpora into knowledge graphs and constructs community hierarchies and summaries to support more structured retrieval and summarization. However, in the "engineering design configuration" problem, simply focusing on "retrieval of subgraphs → generation of summaries / suggestions" often lacks refined reasoning and executable constraint pruning mechanisms for the design decision chain (from requirements to modules, from modules to parameters, from parameters to verification).

[0028] The third approach is a basic design method assisted by Knowledge-Based Engineering (KBE). Related technologies have proposed data / knowledge models for basic ship design, integrating repetitive calculations and data related to main dimensions, lines, power, layout, and structure into a knowledge base, and promoting knowledge reuse through semantic queries. This approach typically relies on manual maintenance of rules and data models. When extending to new ship types or new regulations, the investment in knowledge engineering is significant, and there are still challenges in the unified traceability expression of cross-disciplinary constraints.

[0029] The fourth area is the application of MBSE (Material Business Environment) in ship architecture modeling. Related technical research indicates that MBSE can be used for ship system architecture development and to improve communication and requirements traceability capabilities. Some studies have also used MBSE for modeling operational scenarios and constraints of ship-related functions (such as autonomous ship functions). However, the end-to-end closed-loop path of "automatically converting the structured knowledge of the MBSE model library into a semantically searchable hierarchical index, and further integrating it with LLM to complete online generation / configuration" is still insufficient.

[0030] The aforementioned technologies can solve some problems from natural language requirements to design solution generation, but they still have the following shortcomings: First, since LLM-generated solutions mainly rely on implicit knowledge of model parameters and hint engineering, they are prone to illusions or omissions of key constraints in the absence of external "searchable evidence + executable constraints". Especially in security / regulation-intensive projects, illusions can significantly increase review costs and risks.

[0031] Second, because traditional RAG / GraphRAG is more inclined to "text / knowledge summarization" and lacks a fine reasoning chain and pruning strategy for engineering design "from requirements to modules to parameters and verification", it is prone to the following problems in complex system configuration: the retrieved information is relevant but cannot form an achievable overall architecture; or there are conflicts between different subsystem suggestions such as interface / power / weight / stability that are not discovered in time.

[0032] Third, since ship KBE knowledge bases often require manual extraction of rules and maintenance of data structures and formula models, when requirements change frequently or ship types vary greatly (e.g., from offshore work vessels to green power vessels to special purpose vessels), rules and knowledge structures need to be reconstructed extensively. At the same time, the traceable mapping of multi-source normative clauses (clauses - requirements - design elements) is often difficult to automate.

[0033] Fourth, while simple MBSE modeling can improve architectural clarity and traceability, if there is a lack of semantic indexing and automatic configuration mechanisms for "model reuse / fast retrieval", the conceptual stage may still face problems such as "flattening" of the model library, reliance on manual labels and experience for retrieval, and low efficiency of cross-project reuse.

[0034] Based on the aforementioned shortcomings, this application proposes a method for generating ship design schemes. Specifically, it is a collaborative "MBSE+LLM" method for the ship concept / preliminary design stage, used to quickly and traceably convert multi-source requirements (mission profiles, navigation environment, regulations / classification society rules, performance indicators, cost / schedule constraints, etc.) given by users in natural language into structured overall ship schemes and corresponding systems engineering models. The core idea is to construct a two-stage framework of "offline knowledge construction and hierarchical semantic indexing + online hierarchical retrieval / reasoning and constraint pruning": In the offline stage, the ship MBSE model library is automatically converted into a hierarchical knowledge graph and a semantic vector index is generated; in the online stage, LLM is used to semantically enhance and structure the requirements, followed by top-down parallel retrieval, conflict detection, and constraint pruning on the hierarchical index, outputting a ship design scheme that meets the constraints, while generating a traceability matrix of requirements-functions-physical architecture and interpretable decision-making basis.

[0035] This application's embodiments address how to automatically generate ship design schemes that are engineering-feasible, have consistent constraints, and can output traceable systems engineering models in a short time when user requirements are described in natural language and include implicit constraints and multi-source specifications (SOLAS / classification society rules / enterprise standards / experience rules), and can quickly recalculate and explain the design decision chain "why this was chosen" after requirements change.

[0036] Figure 1 This is a schematic diagram of the electronic device provided in an embodiment of this application. The electronic device 100 can be used to execute the ship design scheme generation method provided in an embodiment of this application. Figure 1 As shown, the electronic device 100 includes: one or more processors 102 and one or more memories 104 storing processor-executable instructions. The processors 102 are configured to execute the ship design generation method provided in the following embodiments of this application.

[0037] The processor 102 may be a gateway, a smart terminal, or a device that includes a central processing unit (CPU), a graphics processing unit (GPU), or other forms of processing units with data processing capabilities and / or instruction execution capabilities. It can process data from other components in the electronic device 100 and control other components in the electronic device 100 to perform desired functions.

[0038] The memory 104 may include one or more computer program products, which may include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. The volatile memory may include, for example, random access memory (RAM) and / or cache memory. The non-volatile memory may include, for example, read-only memory (ROM), hard disk, flash memory, etc. One or more computer program instructions may be stored on the computer-readable storage medium, and the processor 102 may execute the program instructions to implement the ship design scheme generation method described below. Various application programs and various data may also be stored in the computer-readable storage medium, such as various data used and / or generated by the application programs.

[0039] In one embodiment, Figure 1 The illustrated electronic device 100 may further include an input device 106, an output device 108, and a data acquisition device 110, these components being interconnected via a bus system 112 and / or other forms of connection mechanisms (not shown). It should be noted that... Figure 1 The components and structure of the electronic device 100 shown are merely exemplary and not limiting; the electronic device 100 may also have other components and structures as needed.

[0040] The input device 106 may be a device used by a user to input commands, and may include one or more of a keyboard, mouse, microphone, and touchscreen. The output device 108 may output various information (e.g., images or sounds) to the outside (e.g., the user), and may include one or more of a display, speaker, etc. The data acquisition device 110 may acquire a ship MBSE model library and store the acquired data in the memory 104 for use by other components.

[0041] In one embodiment, the components in the example electronic device 100 used to implement the ship design scheme generation method of the present application embodiment can be integrated or distributed. For example, the processor 102, memory 104, input device 106 and output device 108 can be integrated into one unit, while the data acquisition device 110 can be separated.

[0042] In one embodiment, the example electronic device 100 used to implement the ship design scheme generation method of the present application embodiment can be implemented as a smart terminal such as a smartphone, tablet computer, desktop computer, server, vehicle equipment, etc.

[0043] Figure 2 This is a flowchart illustrating a method for generating a ship design scheme according to an embodiment of this application, as shown below. Figure 2 As shown, the method includes steps 210-270.

[0044] Step 210: Obtain the ship MBSE model library and convert the ship MBSE model library into a ship design knowledge graph.

[0045] Before acquiring the ship MBSE model library, the method further includes constructing the ship MBSE model library. Constructing the ship MBSE model library includes: establishing a ship requirements model that includes mappings of ship missions, operational concepts, and regulatory clauses; decomposing the ship missions into ship functions and establishing a functional architecture model, whereby ship functions include navigation functions, positioning functions, transport / operation functions, energy management functions, safety functions, and fire prevention functions; allocating the ship functions to ship subsystems and key equipment / modules, and establishing a physical architecture model, whereby ship subsystems include hull / structure subsystems, propulsion and power subsystems, power generation / distribution subsystems, outfitting subsystems, and mission equipment subsystems; establishing a parameter / analysis model that includes key parameters and calculation relationships, whereby key parameters include weight center of gravity, power balance, propulsion performance, and stability; recording the regulatory / rule clauses to be verified and verification methods, and establishing a verification use case model.

[0046] The process of converting the ship MBSE model library into a ship design knowledge graph includes: reading the model serialization file of the ship MBSE model library and parsing it into an internal object graph, wherein the ship MBSE model library is built using SysML language; determining the nodes in the knowledge graph based on the internal object graph, wherein the types of nodes include requirement nodes, scenario nodes, function nodes, subsystem nodes, equipment / module nodes, parameter nodes, rule / clause nodes, and verification object nodes; establishing the relationships between the nodes to form edges in the knowledge graph, wherein the types of relationships include derived requirements, satisfaction, allocation, composition, interface, constraint, verification, and traceability reference; and constructing the knowledge graph by attaching regulations / rules as clause nodes based on the nodes and edges in the knowledge graph.

[0047] Step 220: Generate standardized natural language descriptions for the nodes in the ship design knowledge graph, and vectorize the natural language descriptions to obtain a node vector library.

[0048] The step of vectorizing the natural language description to obtain a node vector library includes: using the BERT model to map the natural language description into vectors to form a node vector library.

[0049] Step 230: Perform hierarchical clustering based on the node vector library to construct a hierarchical semantic index.

[0050] Specifically, this involves using the HDBSCAN algorithm to perform hierarchical clustering on the node vector library to generate a multi-layered cluster tree, which includes multiple cluster nodes, each representing a node vector of the same category; storing the ship design knowledge graph and the cluster nodes together, and constructing a mapping table between the cluster nodes and the nodes in the ship design knowledge graph.

[0051] Step 240: Obtain the natural language ship design requirements input by the user, and use a large language model to perform semantic enhancement and structured parsing on the natural language ship design requirements to obtain structured requirement data.

[0052] The step of using a large language model to perform semantic enhancement and structured parsing of the natural language ship design requirements includes: using a large language model to transform the natural language ship design requirements into a requirement vector-requirement slot table, wherein the requirement slots include task profile, environment and boundary, strong constraints, objective function, and permissible trade-offs; semantically completing the implicit requirements in the natural language ship design requirements, and marking the completed content as inference terms.

[0053] Step 250: Based on the structured requirement data, perform a top-down hierarchical retrieval on the hierarchical semantic index to obtain a candidate design data set.

[0054] Specifically, this includes: calculating the similarity between the structured requirement data and the top-level cluster nodes of the hierarchical semantic index, and selecting the TopK similarity cluster nodes as candidate top-level cluster nodes; For each of the candidate top-level cluster nodes, the process is expanded downwards in parallel. Based on the mapping table, matching nodes in the ship design knowledge graph are retrieved layer by layer to form a candidate design data set.

[0055] Step 260: Perform constraint pruning on the candidate design data set to obtain target design data that meets the constraint conditions.

[0056] Specifically, this includes performing regulatory / rule applicability filtering, interface consistency filtering, parameter range filtering, and architecture integrity filtering on the candidate design data set to obtain the target design data.

[0057] Step 270: Based on the target design data, synthesize ship design schemes and generate ship design scheme deliverables.

[0058] Specifically, this includes: generating a ship MBSE workpiece based on the target design data; performing engineering feasibility verification and interpretive output on the ship MBSE workpiece to obtain a ship overall scheme report, SysML model file / model service link, requirement traceability matrix, and verification report.

[0059] Figure 3 This is a flowchart illustrating another method for generating ship design schemes according to an embodiment of this application, such as... Figure 3 The diagram illustrates the data flow of this embodiment, including offline and online data flows. The method comprises two main threads: a ship MBSE model library built using languages ​​such as SysML (Systems Modeling Language) serves as the "structured fact base," a knowledge graph / vector index serves as the "retrievalable knowledge layer," and LLM serves as the "requirement understanding and decision orchestrator." SysML, as the MBSE modeling language, can express requirements, structure, behavior, analysis, and verification use cases, providing a linguistic foundation for outputting deliverable systems engineering artifacts. BERT is used to embed node descriptions / requirement descriptions into vectors for similarity retrieval. HDBSCAN is used to form more stable hierarchical semantic clusters in multi-density scenarios, resulting in a "top-down retrieval" index structure. The RAG concept is used to "anchor" the generation process to retrieveable model / rule evidence, reducing illusions and improving updability.

[0060] In the offline knowledge construction and hierarchical indexing stage, that is Figure 3 The goal of this offline data stream is to transform the "flat ship MBSE model library + scattered rule / standard knowledge" into a knowledge structure that is "hierarchically searchable and traceable." Specifically, it includes the following steps: Step A: Build / obtain the ship MBSE model library. This specifically includes: Step A1: Establish the ship requirements model: This includes mission / operation concepts, regulatory clause mappings (which can initially be linked via text references), key performance indicators (KPIs), and placeholders for validation methods. CONOPS (Concept of Operations) documents can be used as input for requirements engineering to extract scenarios, roles, constraints, and objectives.

[0061] Step A2: Establish a functional architecture model: Decompose the task into functions (such as navigation, positioning, transportation / operation, energy management, safety, fire prevention, etc.), and establish interfaces and performance flows between functions.

[0062] Step A3: Establish a physical architecture model: Assign functions to subsystems such as hull / structure, propulsion and power, power generation / distribution, outfitting, mission equipment, and key equipment / modules.

[0063] Step A4: Establish parameter / analysis model: including key parameters and calculation relationships such as weight center of gravity, power balance, propulsion performance, and stability (can be connected to external CAE / calculation scripts).

[0064] Step A5: Establish a verification use case model: Record the regulatory / rule clauses that need to be verified and the verification methods (calculation, simulation, experimentation or document review).

[0065] Step B: Graph transformation from MBSE model to knowledge graph. This specifically includes: Step B1: Read the SysML model serialization file (e.g., XMI, XML Metadata Interchange) and parse it into an internal object graph. Required elements can be extracted from SysML / XMI and converted into a semantic ontology (OWL (data layer) / RDF (ontology layer)), thus supporting semantic understanding and querying; this demonstrates the technical feasibility of the "model → semantic graph" approach.

[0066] Step B2: Generate a ship design knowledge graph (KG).

[0067] The node types include at least: requirement node R, scenario node S, function node F, subsystem node SS, device / module node C, parameter node P, rule / clause node Rule, and verification node V.

[0068] Relationship types include at least: derive, satisfy, allocate, compose, interface, constrain, verify, and trace.

[0069] Step B3: Link the regulatory / rule knowledge into "clause nodes (Rules): for example, SOLAS clause sets, classification society rule chapters, corporate standard entries, etc., and at least save "clause ID / chapter - text - applicable conditions - affected object type - verification method template". The purpose and applicability of SOLAS can serve as a typical example of such a clause library.

[0070] Step C: Generate semantic descriptions and vector indexes for retrieval. This specifically includes: Step C1: Generate a "normalized natural language description" for each node in the KG (or for each reusable subgraph). The description includes: node type, function / device role, typical applicable scenarios, key parameters and interfaces, constraints, and a summary of the relationship with the parent / child nodes.

[0071] Step C2: Vectorize the descriptive text: Use BERT or equivalent embedding models to map the text into vectors, forming a "node vector library".

[0072] Step C3: Perform hierarchical clustering on the node vectors: Use HDBSCAN or an equivalent algorithm to form a multi-level cluster structure and output a "cluster tree / hierarchical index" which includes multiple cluster nodes to support top-down retrieval and rapid narrowing of the search space in the online stage.

[0073] Step C4: Store the hierarchical index and KG together, store the KG in the graph database, store the vector index in the vector database, and establish a mapping table of "cluster node - KG subgraph / node set".

[0074] Step D: Interconnecting Engineering Toolchains and Service-Oriented Models. This specifically includes: Step D1. If the SysML v2 ecosystem is used, the REST interface provided by the OSLC SysML domain specification can be used to access model resources and relationships, thereby achieving toolchain integration for "model as a service".

[0075] Step D2: For objects that need to interact with CAD / PLM, the ISO 10303 (STEP) mechanism can be used to express and exchange product data, which facilitates cross-tool interoperability and long-term archiving; NIST and ISO's overview of STEP emphasizes its ability to exchange product data throughout the entire lifecycle.

[0076] In the offline knowledge construction and hierarchical indexing stage, that is Figure 3 The goal of the online data stream is to take natural language requirements as input, output structured ship design schemes and corresponding MBSE models, and ensure that the data is interpretable and verifiable.

[0077] Step E: Natural Language Requirements Semantic Enhancement and Structured Parsing. Specifically, this includes: Step E1: User input requirements: These may include vessel type / mission (e.g., offshore support, scientific research, green transportation, etc.), navigation area (coastal / deep ocean / polar, etc.), load / personnel capacity, speed / range, operational capabilities, noise / vibration, emission targets, cost / construction period, applicable regulations, etc.

[0078] Step E2: LLM performs requirement deconstruction: converting the input into a structured "requirement vector + requirement slot table", where each slot includes at least: Mission Profile: Voyage phase, operational status percentage, and operational mode; Operational Environment: Sea state, temperature, ice zones, port restrictions; Hard Constraints: Regulatory / classification society provisions, critical safety redundancy levels; Objectives: cost, fuel consumption / carbon emissions, load, comfort, etc. Allowed trade-offs: adjustable range and preferences.

[0079] Step E3: Semantic Enhancement: Complete the implicit requirements, such as inferring endurance and spare parts support requirements from "ocean voyages", and inferring SOLAS-related safety configuration requirements from "manned operations", and label them as "inferred items" for subsequent interpretation and manual verification. The LLM illusion risk and mitigation requirements are pointed out by relevant reviews, so this step requires labeling the inferred items and verifying them with search evidence later.

[0080] Step F: Hierarchical retrieval and reasoning (top-down parallel search + constraint pruning). Specifically, this includes: Step F1: Top-level positioning: Calculate the similarity between the "demand vector" and the top-level cluster nodes of the hierarchical index, and select the TopK cluster nodes with the highest similarity as candidate top-level cluster nodes.

[0081] Step F2: Layered Expansion: For each candidate top-level cluster node, expand it in parallel to the next layer of clusters or node sets, and retrieve the functional subgraphs, system subgraphs and module nodes that are most relevant to the requirements.

[0082] Step F3: Constraint Pruning: Perform consistency and constraint filtering after each level of retrieval, including but not limited to: Regulatory / rule applicability filtering: Based on conditions such as navigation area, crew, and ship type, inapplicable modules are filtered out or necessary modules (such as safety equipment configuration) are added.

[0083] Interface consistency filtering: Detection of interface constraint conflicts such as power, voltage level, flow rate, and spatial envelope; Parameter range filtering: out-of-bounds detection for principal dimensions, center of gravity, power margin, etc. Architectural integrity filtering: Critical functions must be assigned to at least one physical implementation (satisfy / allocate closure).

[0084] Step F4: Termination condition of hierarchical reasoning: When the candidate set converges to a composable set of "function-system-module" and satisfies hard constraints and resolvable conflicts, proceed to scheme synthesis; otherwise, return to the previous step to adjust the search scope or trigger a "requirement clarification" prompt (e.g., prompting the user to confirm the inference item).

[0085] This overall mechanism of "offline hierarchical index building + online multi-level reasoning, parallel search and pruning" has been used in public research to improve the agility of conceptual design for complex systems, and it outperforms baselines without external knowledge structures (such as those relying solely on LLM reasoning) and graph retrieval-enhanced generation baselines.

[0086] Step G: Scheme synthesis and MBSE artifact generation. Specifically, this includes: Step G1: Architecture Template Selection: Select a ship architecture template based on the search results (e.g., electric propulsion / diesel-electric hybrid / conventional propulsion; monohull / cathull; mission-modular deck, etc.).

[0087] Step G2: Automatic configuration: Assign functional node F to system node SS and module node C to form an executable system decomposition structure and generate key interface definitions.

[0088] Step G3: Parameter initialization: Based on the requirements and parameter ranges from historical cases, initialize the main scale, displacement estimation, power demand, fuel / battery capacity, etc.; if necessary, call external calculation scripts or empirical formula libraries.

[0089] Step G4: Generate a system engineering model: Output SysML model increments (e.g., generate / update requirement diagrams, BDD / IBD, parametric diagrams, verification test cases, etc.) and establish a traceability chain of requirement-design elements. SysML supports expressing requirements, structure, behavior, and verification test cases, providing language capabilities for such outputs.

[0090] Step H: Project feasibility verification and explanatory output. This specifically includes: Step H1: Rule Verification: Perform automatic checks on the verification templates associated with the SOLAS / classification society rule clause nodes (meets / does not meet / requires manual review / missing information). SOLAS, as a publicly available description of the minimum safety standard framework, can serve as one of the bases for rule base modeling.

[0091] Step H2: Consistency verification: power balance, energy management, redundancy strategies (such as N+1 for critical equipment), critical interface matching, etc.

[0092] Step H3: Output Explanation: Provide an "evidence chain" for each key selection: requirement slot → retrieved model node / rule node → reason for selection → verification result, and clearly mark the LLM inference items as "not explicitly proposed by the user / inferred by the system / source of evidence".

[0093] Step H4: Output deliverables. Specific deliverables include: a vessel overall program report (structured sections: tasks and constraints, overall program, subsystem configuration, key parameters, risks and pending confirmations); SysML model files / model service links (e.g., using the OSLC interface); a requirement traceability matrix; and a verification report (mapping of regulatory clauses / rules to sections and results).

[0094] In one embodiment, the user inputs in natural language: Design a support vessel for the operation and maintenance of offshore wind farms, with a maximum capacity of 60 people, dynamic positioning capabilities, the ability to safely transport personnel in rough seas, low emissions, an endurance of at least 14 days, and compliance with applicable safety regulations and classification society requirements. The system applying the method of this embodiment then performs the following operations: Requirements Analysis: Identify vessel type and scenario (offshore operations), crew and safety, DP requirements (Demand Planning), range and emission targets, and infer the need for higher power redundancy and fire / lifesaving configurations (marked as inference items).

[0095] Hierarchical retrieval: Entering from the "offshore operation vessel / support vessel" cluster, the system retrieves functional / system subgraphs related to "personnel transfer safety, positioning, power redundancy, and habitability"; the system completes the mapping of safety equipment clauses related to personnel carrying capacity during rule pruning.

[0096] Synthetic output: Generates candidates for propulsion and electric systems (such as diesel-electric / hybrid configurations), DP-related redundant architectures, and living and rescue system configurations, and outputs a "requirement-module-verification" traceability matrix; unprovided navigation area details (temperature zone, maximum sea state level) are listed as items to be confirmed.

[0097] In addition to the embodiments described above, at least the following alternative embodiments may also be included: Embedding model replacement: BERT can be replaced by any embedding model that can map text to vectors; indexing can be replaced by multi-vector indexing or hybrid retrieval (keywords + vectors). The principle of BERT for semantic representation is only provided as an optional implementation basis.

[0098] Clustering and Hierarchical Indexing Alternatives: HDBSCAN can be replaced by hierarchical K-means, hierarchical topic models, or graph community discovery algorithms; GraphRAG's community hierarchy construction and summary generation provide another hierarchical organization approach that can be used to replace or supplement clustering hierarchy.

[0099] Knowledge carrier replacement: In addition to graph databases, the "OWL + triple storage" approach can also be used, combined with a rule engine for reasoning, to automatically convert SysML requirement graphs to OWL.

[0100] Model Interconnection Alternatives: If the SysML v2 OSLC interface is not used, model resource access can also be achieved based on other lifecycle interconnection mechanisms; the OSLC SysML v2 specification is only one of the preferred interconnection methods.

[0101] Output workpiece replacement: In addition to SysML models, data packages compatible with CAD / PLM can also be output; ISO 10303 (STEP) regarding product data exchange / archiving can serve as a standardized reference for output interoperability.

[0102] The solution provided in the above embodiments of this application overcomes the shortcomings of related technologies, such as reliance on manual experience in early ship design, unreliable LLM generation, low efficiency of MBSE model reuse, and difficulty in automatically verifying regulatory constraints. It provides an intelligent generation method for ship design schemes driven by MBSE and a large language model, enabling rapid and traceable conversion from multi-source natural language requirements to structured overall ship schemes and MBSE models. This ensures that the schemes meet regulatory constraints, have consistent parameters, and are engineering-feasible, improving design efficiency and reducing iteration costs and review risks. On the one hand, it achieves automated generation of ship design schemes from natural language requirements, shortening the conceptual design iteration from several days to weeks to hours, significantly improving design efficiency. On the other hand, through a triple mechanism of knowledge graph + hierarchical semantic indexing + constraint pruning, it greatly reduces the LLM illusion and improves engineering usability.

[0103] The devices and methods disclosed in the several embodiments provided in this application can also be implemented in other ways. The device and method embodiments described above are merely illustrative; for example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0104] In addition, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

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

Claims

1. A method for generating ship design schemes, characterized in that, Includes the following steps: Obtain the ship MBSE model library and convert the ship MBSE model library into a ship design knowledge graph; Standardized natural language descriptions are generated for the nodes in the ship design knowledge graph, and the natural language descriptions are vectorized to obtain a node vector library; Based on the node vector library, hierarchical clustering is performed to construct a hierarchical semantic index; The system obtains the ship design requirements input by the user in natural language, and uses a large language model to perform semantic enhancement and structured parsing on the natural language ship design requirements to obtain structured requirement data. Based on the structured requirements data, a top-down hierarchical retrieval is performed on the hierarchical semantic index to obtain a candidate design data set; Perform constraint pruning on the candidate design dataset to obtain target design data that meets the constraints; Based on the target design data, ship design schemes are synthesized, and ship design scheme deliverables are generated.

2. The method for generating ship design schemes according to claim 1, characterized in that, Before obtaining the ship MBSE model library, the method further includes constructing the ship MBSE model library, which includes: Establish a ship demand model that includes mappings of ship missions, operational concepts, and regulatory provisions; The ship's mission is decomposed into ship functions, and a functional architecture model is established. The ship functions include navigation function, positioning function, transportation / operation function, energy management function, safety function, and fire prevention function. The ship's functions are assigned to ship subsystems and key equipment / modules, and a physical architecture model is established. The ship subsystems include hull / structure subsystem, propulsion and power subsystem, power generation / distribution subsystem, outfitting subsystem, and mission equipment subsystem. Establish a parameter / analysis model that includes key parameters and calculation relationships, wherein the key parameters include weight center of gravity, power balance, propulsion performance, and stability; Record the legal / rule clauses that need to be verified and the verification methods, and establish a verification use case model.

3. The method for generating ship design schemes according to claim 1, characterized in that, The process of converting the ship MBSE model library into a ship design knowledge graph includes: The model serialization file of the ship MBSE model library is read and parsed into an internal object diagram. The ship MBSE model library is built using the SysML language. Based on the internal object graph, the nodes in the knowledge graph are determined. The types of the nodes include requirement nodes, scenario nodes, function nodes, subsystem nodes, device / module nodes, parameter nodes, rule clause nodes, and verification object nodes. Establish the relationships between the nodes to form edges in the knowledge graph. The types of relationships include derived requirements, satisfaction, allocation, composition, interface, constraint, verification, and traceability reference. The knowledge graph is constructed by attaching regulations / rules as clause nodes based on the nodes and edges in the knowledge graph.

4. The method for generating ship design schemes according to claim 1, characterized in that, The step of vectorizing the natural language description to obtain a node vector library includes: The BERT model is used to map the natural language description into vectors, forming a node vector library.

5. The method for generating ship design schemes according to claim 1, characterized in that, The step of performing hierarchical clustering processing based on the node vector library to construct a hierarchical semantic index includes: The HDBSCAN algorithm is used to perform hierarchical clustering on the node vector library to generate a multi-layer cluster tree. The cluster tree includes multiple cluster nodes, and each cluster node represents a node vector of the same category. The ship design knowledge graph and the cluster nodes are stored together to construct a mapping table between the cluster nodes and the nodes in the ship design knowledge graph.

6. The method for generating ship design schemes according to claim 1, characterized in that, The process of using a large language model to perform semantic enhancement and structured parsing of the natural language ship design requirements includes: The natural language ship design requirements are transformed into a requirement vector-requirement slot table using a large language model. The requirement slots include task profile, environment and boundary, strong constraints, objective function, and permissible trade-offs. The implicit requirements in the natural language ship design requirements are semantically completed, and the completed content is marked as inference terms.

7. The method for generating ship design schemes according to claim 5, characterized in that, The step involves performing a top-down hierarchical retrieval on the hierarchical semantic index based on the structured requirements data to obtain a candidate design data set, including: The similarity between the structured requirement data and the top-level cluster nodes of the hierarchical semantic index is calculated, and the TopK cluster nodes with the highest similarity are selected as candidate top-level cluster nodes. For each of the candidate top-level cluster nodes, the process is expanded downwards in parallel. Based on the mapping table, matching nodes in the ship design knowledge graph are retrieved layer by layer to form a candidate design data set.

8. The method for generating ship design schemes according to claim 1, characterized in that, The step of performing constraint pruning on the candidate design data set to obtain target design data that meets the constraints includes: The candidate design data set is subjected to regulatory / rule applicability filtering, interface consistency filtering, parameter range filtering, and architecture integrity filtering to obtain the target design data.

9. The method for generating ship design schemes according to claim 1, characterized in that, The process of synthesizing ship design schemes based on the target design data and generating ship design deliverables includes: Based on the target design data, generate the ship MBSE workpiece; The engineering feasibility of the aforementioned ship MBSE workpiece is verified and explained, resulting in a ship overall scheme report, SysML model files / model service links, a requirement traceability matrix, and a verification report.

10. An electronic device, characterized in that, The electronic device includes: processor; Memory used to store processor-executable instructions; The processor is configured to execute the ship design scheme generation method according to any one of claims 1-9.

Images