Underwater equipment requirement generation method and device based on sysml design element

Abstract

The application discloses a method and device for generating underwater equipment requirements based on SysML design elements, and the method comprises the following steps: obtaining a requirement generation request for target underwater equipment; in response to the requirement generation request, extracting a proxy port (Proxy Port), a value attribute (Value Property) and all Part Properties used as component types from a SysML design model of the underwater equipment; generating a functional requirement of a next system level corresponding to the underwater equipment according to the Part Property; generating an interface requirement of the next system level corresponding to the underwater equipment according to the Proxy Port; and generating a performance requirement of the next system level corresponding to the underwater equipment according to the Value Property. The application can automatically analyze the underwater equipment, generate the functional requirement, the interface requirement and the performance requirement of the next system level, and improve the efficiency of requirement generation and the uniformity of requirement description.

Description

Technical Field

[0001] This invention relates to the cross-application field of system modeling technology and underwater equipment engineering design, and in particular to a method and device for generating underwater equipment requirements based on SysML design elements. It focuses on the application of model-based systems engineering (MBSE) and system modeling language (SysML) in the requirements engineering of underwater equipment R&D and design scenarios, and focuses on the automatic generation and traceability management of design requirements in the cross-system level iteration process of underwater equipment. Background Technology

[0002] As underwater equipment continues to develop towards automation and intelligence, underwater equipment systems have become complex mega-systems involving multiple professional fields such as mechanics, control, electronics, hydraulics, and software. Traditional document-based design methods are difficult to support the needs of cross-domain and multi-level collaborative research and development.

[0003] Model-Based Systems Engineering (MBSE) uses integrated digital system models as the sole authoritative source of information throughout the entire system development process. These models encompass all dimensions of information required for system development, and various charts, reports, and technical documents are considered views or outputs of the model. MBSE has become a core technological approach for underwater equipment system development. Systems Modeling Language (SysML), as the most mainstream standardized modeling language in the MBSE field, uses various types of charts to provide a comprehensive description of the system and is widely used in the requirements analysis, architecture design, and verification of underwater equipment.

[0004] In the hierarchical R&D process of underwater equipment, system requirements need to be decomposed and passed down level by level: system level, subsystem level, and equipment level. Currently, the industry generally uses a manual method to complete the hierarchical transformation of requirements: after designers use SysML to complete the system architecture model of the upper level, they manually sort out the design elements in the model and write them one by one to form the technical requirements of the next level subsystem, which serve as the input basis for downstream design.

[0005] Because underwater equipment systems have many levels, cover a wide range of specialties, and have complex parameter dimensions, this manual conversion method is not only labor-intensive and has a long development cycle, but it is also prone to problems such as missing requirements and inconsistent descriptions, making it difficult to ensure the accuracy and consistency of requirement transmission, thus restricting the development efficiency and design quality of underwater equipment. Summary of the Invention

[0006] To address the aforementioned problems and technical requirements, the inventors have proposed a method and apparatus for generating underwater equipment requirements based on SysML design elements, aiming to improve the efficiency of requirement generation at the next system level and the uniformity of requirement description. The technical solution of this invention is as follows: In a first aspect, this application provides a method for generating underwater equipment requirements based on SysML design elements, comprising the following steps: Obtain the requirement generation request for the target underwater equipment; In response to the requirement generation request, the proxy port, value property, and all part properties used as part types are extracted from the SysML design model of the underwater equipment. Generate the functional requirements of the next system level corresponding to the underwater equipment based on the Part Property; Generate the interface requirements for the next system level corresponding to the underwater equipment based on the Proxy Port; Generate the performance requirements for the next system level corresponding to the underwater equipment based on the Value Property.

[0007] The further technical solution involves generating the functional requirements of the next system level corresponding to the underwater equipment based on the Part Property, including: For each underwater equipment Part Property, determine the Call Behavior Action that has an allocation association with the Part Property; Get the name of the Behavior invoked by the Call Behavior Action, and generate the corresponding underwater equipment functional requirements for the PartProperty based on the name.

[0008] Its further technical solution is to generate the interface requirements of the next system level corresponding to the underwater equipment based on the Proxy Port, including: For each underwater equipment's Proxy Port, obtain the corresponding InterfaceBlock; Use the name of the Interface Block as the name of the interface requirement; Get the direction property of the Flow Property in the Interface Block, and use the direction property as the interface direction; Obtain the connection relationship Connector of the Proxy Port, and check whether both ends of the Connector are PartProperty. If so, use the type name of the Part Property of the other end of the Connector as the interface interaction object; otherwise, skip the Connector. Based on the interface requirement name, interface direction, and interface interaction object, generate the underwater equipment interface requirements corresponding to the Proxy Port.

[0009] The further technical solution involves generating the performance requirements of the underwater equipment at the next system level based on the Value Property, including: For each underwater equipment's Value Property, the name attribute of the Value Property is used as the name of the performance requirement; Use the defaultValue property of the Value Property as the required value; Use the `unit` attribute of the requirement value as the unit of the requirement value; The underwater equipment performance requirements are generated based on the name, required value, and unit of the performance requirement.

[0010] A further technical solution involves, after generating functional requirements, interface requirements, and performance requirements, the method further includes: Establish functional requirements, interface requirements, and performance requirements separately, and trace their relationship with the source design elements of underwater equipment at the previous system level.

[0011] The further technical solution involves establishing a traceability relationship between functional requirements and source design elements of underwater equipment at the higher system level, including the following steps: Obtain the identifier corresponding to the underwater equipment behavior element of the previous system level; Match the identifiers with the generated functional requirements to obtain the target functional requirements; Establish a traceability relationship between behavioral elements and target functional requirements.

[0012] The further technical solution involves establishing a traceability relationship between interface requirements and the source design elements of underwater equipment at the higher system level, including the following steps: Get the name of the Interface Block corresponding to the Proxy Port of the underwater equipment in the previous system level; Match the name with the generated interface requirements to obtain the target interface requirements; Establish a traceability relationship between the Proxy Port element and the target interface requirements.

[0013] The further technical solution involves establishing a traceability relationship between performance requirements and source design elements of underwater equipment at the higher system level, including the following steps: Retrieve the Value Property and Constraint Block of the underwater equipment from the previous system level; Match the name of the Value Property with the generated performance requirements to obtain the first target performance requirement; Establish a traceability relationship between the Value Property and the primary target performance requirement; Parse the constraint parameters and constraint expressions in the Constraint Block; The constraint expression is converted into requirement text, and the requirement text and / or constraint parameters are matched with the performance requirements to obtain the second target performance requirement. Establish a traceability relationship between the Constraint Block and the second target performance requirements.

[0014] A further technical solution involves, after obtaining the traceability relationship, the method further including: Generate a traceability matrix for underwater equipment demand based on traceability relationships; The relationship matrix is ​​visualized.

[0015] Secondly, this application also provides an underwater equipment requirements generation device based on SysML design elements, comprising: The request acquisition module is used to acquire the requirement generation request for the target underwater equipment; The element extraction module is used to extract the proxy port, value property, and all part properties used as part types from the SysML design model of the underwater equipment in response to the requirement generation request. The functional requirements generation module is used to generate functional requirements for the next system level of underwater equipment based on the Part Property. The interface requirement generation module is used to generate interface requirements for the next system level of underwater equipment based on the Proxy Port. The performance requirements generation module is used to generate the performance requirements of the next system level for underwater equipment based on the Value Property.

[0016] The beneficial technical effects of this invention are: 1. Improve the efficiency of requirement generation and standardize expression. By automatically parsing the PartProperty, Proxy Port and Value Property elements in the SysML model of underwater equipment, the system automatically generates three types of requirements for the next system level: function, interface and performance. This replaces the manual method of sorting and entering each requirement one by one, which greatly reduces the workload of requirement decomposition in the multi-level development of underwater equipment, and avoids inconsistent descriptions caused by manual conversion, ensuring the standardization and consistency of requirement expression.

[0017] 2. Ensure the accuracy of requirement communication. Functional requirements are directly derived from the behavior definitions already assigned in the model, while interface and performance requirements are extracted from the inherent attributes of model elements. The content of the requirements strictly matches the upper-level design intent to avoid deviations caused by manual interpretation of the model. 3. Improve the engineering effectiveness of interface requirements. Embed connection relationship validation logic when generating interface requirements to filter out invalid interfaces with no practical connection meaning, and output complete interface requirements including interface name, transmission direction, and interaction objects to ensure that the requirements have engineering implementation value. 4. Build full-dimensional requirement traceability capabilities. It can automatically establish traceability relationships between various requirements and the previous level source design elements, and quickly locate the affected downstream requirements when the upper-level design changes; performance requirements are simultaneously associated with parameter attributes and constraint rules, covering full-dimensional traceability and supporting requirement management throughout the entire R&D cycle of underwater equipment. 5. Reduce requirements management costs. By visually displaying the correspondence between design elements and requirements through a traceability matrix, it is easy to intuitively verify the coverage and completeness of requirements, thereby improving the efficiency of requirements review and change analysis. Attached Figure Description

[0018] Figure 1 A flowchart illustrating a method for generating underwater equipment requirements based on SysML design elements, provided in this application embodiment; Figure 2 This application provides a schematic flowchart of a method for generating functional requirements for underwater equipment. Figure 3 This application provides a schematic flowchart of a method for generating interface requirements for underwater equipment. Figure 4 This is a schematic flowchart of a method for generating performance requirements for underwater equipment, provided in an embodiment of this application. Figure 5 A flowchart illustrating a method for establishing a traceability relationship between functional requirements and source design elements at the higher system level, as provided in an embodiment of this application. Figure 6 A flowchart illustrating a method for establishing a traceability relationship between interface requirements and source design elements at the previous system level, as provided in an embodiment of this application. Figure 7 A flowchart illustrating a method for establishing a traceability relationship between performance requirements and source design elements at the previous system level, provided in an embodiment of this application. Figure 8 A schematic diagram of a traceability matrix provided in an embodiment of this application; Figure 9 A schematic diagram of an underwater equipment requirements generation device based on SysML design elements is provided for an embodiment of this application. Figure 10 This is a schematic diagram of the physical structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0019] The specific embodiments of the present invention will be further described below with reference to the accompanying drawings.

[0020] One embodiment of this application provides a method for generating underwater equipment requirements based on SysML design elements. This method involves developing a plugin that automatically creates functional requirements, interface requirements, and performance requirements based on functional elements, interface elements, and attribute parameter elements generated during the modeling process at the previous system level. This improves the efficiency of automatic requirement generation, and the generated requirements are more consistent in description and less prone to errors.

[0021] This method can be applied to electronic devices, including terminals and servers; the terminals can specifically be smartphones, tablets, computers, personal digital assistants (PDAs), etc.; the servers can specifically be application servers or web servers. Figure 1 A flowchart illustrating a method for generating underwater equipment requirements based on SysML design elements, provided in this application embodiment, includes: Step 101: Obtain the requirements generation request for the target underwater equipment; Step 102: In response to the requirement generation request, extract the Proxy Port, Value Property, and all Part Properties used as part types from the SysML design model of the underwater equipment; Step 103A: Generate the functional requirements for the next system level corresponding to the underwater equipment based on the Part Property; Step 103B: Generate the interface requirements for the next system level corresponding to the underwater equipment based on the Proxy Port; Step 103C: Generate the performance requirements for the next system level corresponding to the underwater equipment based on the Value Property.

[0022] In practice, users interact with SysML design models (such as Cameo Systems Modeler) and select a specific underwater device within the model. This underwater device typically represents a Block element of a system or subsystem. Users trigger a generation request by right-clicking the Block and selecting a function button, such as "Automatic Requirements Generation," from the context menu.

[0023] Once the plugin is triggered, a configuration dialog box may pop up, guiding the user to select or create a target package to store the upcoming requirements and traceability matrix. This ensures that the generated products are stored in an organized manner within the model library.

[0024] Once the plugin receives the target block, it automatically scans and extracts its key design elements. This is the foundation for all subsequent generation steps. The plugin queries the SysML metamodel API to obtain three core design elements: all PartProperties used as part types, all Proxy Ports, and all Value Properties. Detailed descriptions of each element are as follows: Part Properties used as component types refer to attributes whose "type" is another Block. They are used to characterize the entity components of the target Block and can be found through Allocate relationships. Taking an autonomous underwater vehicle (AUV) as an example, if the target Block is "Underwater Vehicle System," then subsystems such as the propulsion system, navigation and positioning system, pressure hull, and energy system are all Part Properties under this Block. Each Part Property corresponds to a subsystem-level Block, representing a component unit of the underwater equipment, and can be associated with the behaviors assigned to that component through Allocate relationships.

[0025] A Proxy Port represents the interface point through which a target Block interacts with the external environment or other components. It belongs to the target Block and can be found through the Owner relationship. Taking an underwater vehicle system as an example, underwater acoustic communication ports, bus control ports, DC power input ports, and sensor data acquisition ports are all Proxy Ports. Each Proxy Port corresponds to a specific Interface Block, which defines the interface interaction specifications and is used to realize the transmission of signals, data, and energy between various subsystems of underwater equipment or between the equipment and external devices.

[0026] Value Properties represent quantifiable attributes such as performance indicators and physical parameters of a target Block. They belong to the target Block and can also be searched through Owner relationships. Taking an underwater vehicle system as an example, quantifiable parameters such as maximum diving depth, maximum speed, design life, overall weight, rated operating power, and operating water depth all belong to Value Properties. Each parameter contains three core types of information: name, default value, and unit, and is the direct carrier of the performance indicators of underwater equipment.

[0027] After obtaining the Part Property, Proxy Port, and Value Property, the plugin automatically generates the functional requirements for the next system level of the underwater equipment corresponding to the Part Property, the interface requirements for the next system level of the underwater equipment corresponding to the Proxy Port, and the performance requirements for the next system level of the underwater equipment corresponding to the Value Property. It should be noted that the generation of functional requirements, interface requirements, and performance requirements can be parallel or sequential; this embodiment does not specifically limit this process.

[0028] After generating functional requirements, interface requirements, and performance requirements, all generated functional requirements, interface requirements, and performance requirements are categorized and organized in the target package according to predefined rules (such as requirement ID numbering rules) to form a well-structured requirement specification catalog, which can also be called a requirement model library.

[0029] This embodiment improves the efficiency of requirement generation and the uniformity of requirement description by automatically analyzing underwater equipment and generating functional requirements, interface requirements, and performance requirements for the next system level.

[0030] The following sections will introduce the automatic generation methods for each type of requirement: (1) Automated generation of functional requirements: Figure 2 This is a schematic flowchart of a method for generating functional requirements for underwater equipment provided in an embodiment of this application, as shown below. Figure 2 As shown, it includes: Step 201: Traverse all extracted Part Properties; for each extracted Part Property (such as "Propulsion System"), perform the following steps.

[0031] Step 202: Trace the behavior assignment; based on the Allocate from relationship of this Part Property, find the Call Behavior Action assigned to it in the upstream design process.

[0032] Step 203: Extract the behavior name; obtain the name of the Behavior (usually an Activity) invoked by the Call Behavior Action. This name describes the specific function that the component needs to perform.

[0033] Step 204: Generate Requirements; Based on the name of this Behavior, create a functional requirement for underwater equipment. For the propulsion system Part Property of underwater equipment, typical functional requirements are as follows: if the associated Behavior name is "Underwater cruise control", then the generated functional requirement is to perform underwater cruise control; if the associated Behavior name is "Propulsion power adjustment", then the generated functional requirement is to perform propulsion power adjustment.

[0034] In this embodiment, when automatically generating functional requirements, the generated requirement names are directly derived from the names of Behaviors explicitly defined in the model, making the requirements more consistent with the design intent.

[0035] (2) Automated generation of interface requirements: Figure 3 This is a schematic flowchart of a method for generating interface requirements for underwater equipment provided in an embodiment of this application, as shown below. Figure 3 As shown, it includes: Step 301: Traverse all extracted Proxy Ports; for each Proxy Port (e.g., "Sensor Data Acquisition Port"), perform the following steps.

[0036] Step 302: Determine the interface type; obtain the Type of the Proxy Port, i.e., its corresponding InterfaceBlock. Use the name of this Interface Block as the name of the interface requirement (e.g., "RS-485 Underwater Sensor Data Interface").

[0037] Step 303: Determine the interface direction; read the direction attribute (such as in / out / inout) of the Flow Property in the Interface Block above, and use it as the interface direction.

[0038] Step 304: Determine the interface object; analyze the connection relationship Connector connected to the Proxy Port. If both ends of the Connector are Part Properties, then record the Type name of the Part Property on the other end of the Connector as the interface interaction object (such as "Multi-parameter water environment sensor module"). Otherwise, skip the Connector.

[0039] Step 305: Generate Requirements; Based on the interface requirement name, interface direction, and interface interaction object, generate a complete interface requirement for underwater equipment. For the sensor data acquisition port of underwater equipment, a typical interface requirement is: to receive water environment acquisition data output from a multi-parameter water environment sensor module via an RS-485 underwater sensor data interface.

[0040] This embodiment improves the efficiency of interface requirement generation by automatically generating interface requirement names, interface directions, and interface interaction objects. Furthermore, it incorporates design rule checks during interface requirement generation to ensure that the generated requirements are based on interfaces with actual connection significance.

[0041] (3) Automated generation of performance requirements: Figure 4 This is a schematic flowchart of a method for generating performance requirements for underwater equipment provided in an embodiment of this application, as shown below. Figure 4 As shown, it includes: Step 401: Iterate through all extracted Value Properties; for each Value Property (such as “Design Life”), perform the following steps.

[0042] Step 402: Read parameter information; directly read the name, defaultValue, and unit of the Value Property. Here, name is the name of the performance requirement (e.g., "design life"); defaultValue is the requirement value (e.g., "15"); and unit is the unit of the requirement value (e.g., "years").

[0043] Step 403: Generate requirements; combine the name, value and unit to generate a performance requirement for underwater equipment, such as the expected service life of the entire underwater equipment is 15 years.

[0044] This application embodiment improves the efficiency of performance requirement generation by automatically generating performance requirement names, requirement values, and units, and automatically generating performance requirements based on the performance requirement names, requirement values, and units of the requirement values.

[0045] Based on the above embodiments, after generating functional requirements, interface requirements, and performance requirements, a traceability relationship can be established between the generated functional requirements, interface requirements, and performance requirements and the source design elements of underwater equipment at the previous system level. It should be noted that the establishment of the above traceability relationship can be parallel or sequential; this application does not specifically limit this.

[0046] The following sections will introduce the traceability relationships between functional requirements and the source design elements of underwater equipment at the previous system level, the traceability relationships between interface requirements and the source design elements of underwater equipment at the previous system level, and the traceability relationships between performance requirements and the source design elements of underwater equipment at the previous system level: (1) The traceability relationship between functional requirements and the source design elements of underwater equipment at the previous system level Figure 5This application provides a flowchart illustrating a method for establishing a traceability relationship between functional requirements and source design elements of underwater equipment at a higher system level, as illustrated in the embodiments of this application. Figure 5 As shown, it includes: Step 501: Obtain the identifier corresponding to the behavior element at the previous system level. This step is fundamental to the matching process and aims to extract key information from the source that uniquely identifies the behavior element. Behaviors at the previous system level are behaviors (primarily Activities or Opaque Behaviors) invoked by Call Behavior Actions used during the generation of functional requirements. For example, using the Activity "Underwater Cruise Control" assigned to the Propulsion System PartProperty at the previous system level as the source design element, the plugin reads the name of this behavior element through the modeling tool's API as the matching identifier. This name typically follows certain naming conventions, which are a prerequisite for the success of this method. Common naming conventions include including the requirement ID: for example, "SR-F003_Underwater Cruise Control," where "SR-F003" is the system-level functional requirement number and "Underwater Cruise Control" is the functional description; both serve as the core identifier for subsequent matching.

[0047] Step 502: Match the identifier with the generated functional requirements to obtain the target functional requirement. The plugin searches in the automatically generated subsystem-level functional requirement library (i.e., the package or directory containing all functional requirements automatically created in previous steps). The identifier extracted in step 501 (such as "SR-F003_Underwater cruise control") is compared with the name of each functional requirement in the requirement library, that is, the functional requirement entry previously generated based on this Behavior and named "Execute Underwater Cruise Control" is located and identified as the target functional requirement.

[0048] Understandably, matching rules can include exact matching, keyword matching, and ID matching. Exact matching requires the identifier to be exactly the same as the requirement name, which is the ideal and most reliable scenario. Keyword matching identifies core words in the identifier (such as "cruise control") and searches for these words in the requirement name; this can handle minor differences in names. ID matching prioritizes identifying and matching the requirement ID portion of the name (such as "SR-F003") because IDs are unique and offer the highest matching accuracy. If a match is successful, it means a requirement has been found whose name highly matches the identifier of the behavioral element; this requirement is then identified as the "target functional requirement." If a match fails, it means no requirement was found, and the plugin may log a warning and mark this relationship as requiring manual intervention.

[0049] Step 503: Establish the dependency relationship between behavioral elements and target functional requirements. The plugin automatically creates a dependency relationship in the SysML design model, pointing from the parent behavioral element to the target functional requirement. For example, the relationship starts at the system-level "Underwater cruise control" Activity behavioral element and ends at the generated "Execute underwater cruise control" subsystem functional requirement, and this dependency relationship is defined as a SysML standard < <refine>The (refinement) relationship is a standard traceability relationship defined in the SysML standard, which clearly represents the refined traceability semantics of upper-level design behavior on lower-level functional requirements.

[0050] This embodiment establishes a traceability relationship between behavioral elements and target functional requirements. When a behavioral element at the previous system level changes, the functional requirements that need to be changed synchronously can be determined based on the traceability relationship.

[0051] (2) The traceability relationship between interface requirements and the source design elements of underwater equipment in the previous system level Figure 6 This application provides a flowchart illustrating a method for establishing a traceability relationship between interface requirements and source design elements of underwater equipment at the previous system level, as illustrated in the embodiments of this application. Figure 6 As shown, it includes: Step 601: Obtain the source design element identifier from the previous system level. Take as input the set of all Proxy Port elements used to generate interface requirements in the previous system level (system-level master control system block). Each Proxy Port has been used to generate one or more interface requirements. The plugin iterates through each Proxy Port in the above list, accessing its type attribute via the modeling tool API. It obtains the corresponding Interface Block name, which serves as the core identifier for subsequent matching. For example, if a Proxy Port's type is an Interface Block named "RS-422_Data Interface", then "RS-422_Data Interface" is the core identifier for this port.

[0052] Step 602: Match the identifier with the generated interface requirements to obtain the target interface requirement. The plugin compares each identifier obtained in Step 601 (e.g., "RS-422_Data Interface") with the name of each requirement in the generated subsystem-level interface requirement library (i.e., the package or directory containing all interface requirements automatically created in previous steps). Similarly, the matching rules can include exact matching and fuzzy matching. Since the name of the interface requirement directly comes from the Interface Block name, exact matching can locate the corresponding target interface requirement. Fuzzy matching takes into account possible differences in character case, spaces, or special symbols. The plugin may use fuzzy string matching (e.g., removing spaces, ignoring case) as an auxiliary means to ensure robustness. After a successful match, a unique corresponding interface requirement entry can be found and identified as the "target interface requirement".

[0053] Step 603: Establish the traceability relationship between the Proxy Port element and the target interface requirement. The plugin automatically creates a dependency relationship in the SysML design model, pointing from the parent Proxy Port element to the target interface requirement. For example, the relationship starts at the Proxy Port—the sensor data acquisition port—at the previous system level, and ends at the matched target interface requirement. This dependency relationship is then defined as a SysML standard <...> <refine>> (Refinement) relationship, which represents the elaboration and traceability semantics of the requirements of the lower interface by the upper interface design elements.

[0054] This embodiment establishes a traceability relationship between Proxy Port elements and target functional requirements. When the Proxy Port element at the previous system level changes, the functional requirements that need to be changed synchronously can be determined based on the traceability relationship.

[0055] (3) The traceability relationship between performance requirements and the source design elements of underwater equipment at the previous system level This method establishes a two-way, multi-level traceability relationship for performance requirements. It handles two different types of source design elements: Value Property: representing the "design value" of performance parameters, which is linked to the requirements. <satisfy>> (Satisfaction) Relationship; Constraint Block: Represents the "validation rules" for performance parameters, establishing a relationship with the requirements. <refine>> (Refined) Relationships. Through the above method, we not only know which parameter fulfills a performance requirement, but also what rules it should be verified according to. The following explanation uses the example of the previous system level (underwater autonomous vehicle system level) where ValueProperty represents the maximum diving depth and Constraint Block represents the diving depth safety constraint.

[0056] Figure 7 This application provides a flowchart illustrating a method for establishing a traceability relationship between performance requirements and source design elements of underwater equipment at the previous system level, as illustrated in the embodiments of this application. Figure 7 As shown, it includes: Step 701: Obtain the Value Property from the previous system level and match it with the first target performance requirement. Take the Value Property from the previous system level that serves as the source of the performance requirement (e.g., ValueProperty named Maximum Diving Depth of Underwater Equipment, with a defaultValue of 300 and a unit of meters) as input. The plugin compares the name of this Value Property (e.g., "Maximum Diving Depth") with the requirement names in the generated subsystem-level performance requirement library (i.e., the package or directory containing all performance requirements automatically created in previous steps). Performance requirement entries with identical or highly similar names (e.g., maximum diving depth of 300 meters) are identified as the first target performance requirement.

[0057] Step 702: Establish the traceability relationship between the Value Property and the first target performance requirement. The plugin automatically creates a <line> in the SysML design model that points from the parent Value Property to the first target performance requirement. <satisfy>Dependency relationships indicate that the attribute value is the implementation carrier of the corresponding performance requirement.

[0058] Step 703: Obtain the Constraint Block from the previous system level. Take the Constraint Block (e.g., "Dive Depth Safety Constraint") associated with the performance parameter (e.g., "Dive Depth Parameter") from the previous system level as input. This constraint block contains two key parts: first, the constraint parameter, usually a reference to a Value Property; and second, the constraint expression, which defines the equations or logical expressions of the constraints between parameters (e.g., depth ≤ 300), used to clarify the verification rules for this performance indicator.

[0059] Step 704: Convert the constraint expression into requirement text. The plugin parses the constraint expression, identifying the operand (depth), operator (≤), and constant value (300). Operators are mapped to natural language terms (e.g., ≤ is mapped to "less than or equal to" or "not exceeding"). Units (e.g., "meters") are obtained from the associated Value Property and integrated into the text. Finally, it is converted into standardized requirement text, for example: Maximum diving depth not exceeding 300 meters.

[0060] Step 705: Match the second target performance requirement corresponding to the Constraint Block. The plugin uses the transformed requirement text as keywords to search and match in the performance requirement library. Intelligent matching can be used, by finding performance requirements that contain the same keywords (such as "depth", "less than or equal to", "300", "meters") in their names or descriptions, locating the corresponding performance requirement entries, and identifying the successfully matched entries as the second target performance requirement.

[0061] Step 706: Establish the traceability relationship between the Constraint Block and the second target performance requirement. The plugin automatically creates a trace in the SysML design model that points from the parent Constraint Block to the second target performance requirement. <refine>Dependency relationships indicate that the constraint rule serves as the basis for verifying the corresponding performance requirements.

[0062] It should be noted that steps 701-702 can be executed in parallel with steps 703-706, or they can be executed in sequence. This application embodiment does not make specific limitations on this.

[0063] This embodiment establishes a traceability relationship between the Value Property and the first target performance requirement, as well as a traceability relationship between the Constraint Block and the second target performance requirement. When the Value Property and Constraint Block at the previous system level change, the performance requirements that need to be changed synchronously can be determined based on the traceability relationship.

[0064] Based on the above embodiments, after obtaining the traceability relationship, the method further includes: generating a traceability relationship matrix based on the traceability relationship, and visually displaying the traceability relationship matrix.

[0065] In its implementation, the plugin first scans and collects all trace relationships across the entire model or a specified model. These trace relationships are stored in the model as dependencies with specific types (stereotypes). For each trace relationship, the plugin extracts its core metadata, including: the source element (the starting point of the relationship), such as Activity, Proxy Port, Value Property, Constraint Block; the target element (the ending point of the relationship), i.e., various generated requirements (functionality, interface, performance requirements); and the relationship type, such as < <refine> >、< <satisfy>>

[0066] Based on the obtained traceability relationships, a traceability matrix is ​​established. In one possible implementation, rows representing "design elements" or "verification elements"—the source end in the traceability relationship—are used as matrix rows, including all traced Activities (behaviors), Block / Part Properties (structures), Proxy Ports (interfaces), Value Properties (parameters), and Constraint Blocks (constraints). Columns representing "requirements"—the target end in the traceability relationship—are used as matrix columns, including all generated functional requirements, interface requirements, and performance requirements. The intersections of the matrix rows and columns are represented by cells. If a traceability relationship exists between the corresponding design element and requirement, the cell is marked (e.g., with an X, √, Refine, Satisfy, or a relationship type icon). If no relationship exists, the cell is empty. Figure 8 A schematic diagram of a traceability matrix provided for an embodiment of this application, such as... Figure 8 As shown in the diagram, the intersections of rows and columns corresponding to behavioral elements and target functional requirements are automatically selected or filled based on the traceability relationship, providing an intuitive, tabular traceability view. The numbers in the diagram represent the sequence number of the requirement item, and the arrows represent the source of that requirement, ensuring that each downstream requirement has a clear upstream design basis, achieving full-chain traceability of requirements. It should be noted that... Figure 8 The specific content in the traceability relationship shown is just an example. Depending on the system, the specific content of the traceability relationship will be different.

[0067] Figure 9 This application provides a schematic diagram of an underwater equipment requirements generation device based on SysML design elements. This device can be a module, program segment, or code on an electronic device. It should be understood that this device is similar to the one described above. Figure 1 The method implementation corresponds to this and can be executed. Figure 1 The specific functions of the device involved in each step of the method embodiment can be found in the description above; to avoid repetition, detailed descriptions are omitted here. The device includes: a request acquisition module 901, an element extraction module 902, a functional requirement generation module 903, an interface requirement generation module 904, and a performance requirement generation module 905, wherein: The request acquisition module 901 is used to acquire the requirement generation request for the target underwater equipment; the element extraction module 902 is used to extract the proxy port, value property, and all part properties used as part types from the SysML design model of the underwater equipment in response to the requirement generation request; the functional requirement generation module 903 is used to generate the functional requirements of the next system level of the underwater equipment based on the part properties; the interface requirement generation module 904 is used to generate the interface requirements of the next system level of the underwater equipment based on the proxy port; and the performance requirement generation module 905 is used to generate the performance requirements of the next system level of the underwater equipment based on the value property.

[0068] Based on the above embodiments, the functional requirements generation module 903 is specifically used for: For each Part Property, determine the Call BehaviorAction that has an allocation association with the Part Property; obtain the name of the Behavior invoked by the Call Behavior Action, and generate the corresponding underwater equipment functional requirements for the Part Property based on the name.

[0069] Based on the above embodiments, the interface requirement generation module 904 is specifically used for: For each Proxy Port, obtain the Interface Block corresponding to the Proxy Port; use the name of the Interface Block as the interface requirement name; obtain the direction property of the Flow Property in the Interface Block and use the direction property as the interface direction; obtain the Connector of the Proxy Port, and check whether both ends of the Connector are Part Properties. If so, use the Type name of the PartProperty of the other end of the Connector as the interface interaction object; otherwise, skip the Connector; generate the underwater equipment interface requirements corresponding to the Proxy Port based on the interface requirement name, interface direction, and interface interaction object.

[0070] Based on the above embodiments, the performance requirement generation module 905 is specifically used for: For each Value Property, the name attribute of the Value Property is used as the name of the performance requirement; the defaultValue attribute of the Value Property is used as the requirement value; and the unit attribute of the requirement value is used as the unit of the requirement value. The underwater equipment performance requirements are generated based on the performance requirement name, requirement value, and unit of the requirement value.

[0071] Based on the above embodiments, the device also includes a traceability relationship establishment module, which is used to establish traceability relationships between functional requirements, interface requirements, and performance requirements and the source design elements of underwater equipment at the previous system level.

[0072] Based on the above embodiments, the traceability relationship establishment module is specifically used to: obtain the identifier corresponding to the underwater equipment behavior element of the previous system level; match the identifier with the generated functional requirements to obtain the target functional requirements; and establish the traceability relationship between the behavior element and the target functional requirements.

[0073] Based on the above embodiments, the traceability relationship establishment module is also specifically used to: obtain the name of the Interface Block corresponding to the Proxy Port of the underwater equipment at the previous system level; match the name with the generated interface requirements to obtain the target interface requirements; and establish a traceability relationship between the Proxy Port element and the target functional requirements.

[0074] Based on the above embodiments, the traceability relationship establishment module is further specifically used to: obtain the underwater equipment Value Property and Constraint Block from the previous system level; match the name of the Value Property with the generated performance requirements to obtain the first target performance requirement; establish a traceability relationship between the Value Property and the first target performance requirement; parse the constraint parameters and constraint expressions in the Constraint Block; convert the constraint expressions into requirement text, and match the requirement text and / or constraint parameters with the performance requirements to obtain the second target performance requirement; and establish a traceability relationship between the Constraint Block and the second target performance requirement.

[0075] Based on the above embodiments, the device further includes a display module for generating a traceability matrix based on the traceability relationship and for visually displaying the traceability matrix.

[0076] Figure 10 This is a schematic diagram of the physical structure of the electronic device provided in the embodiments of this application, such as... Figure 10 As shown, the electronic device includes: a processor 1001, a memory 1002, and a bus 1003; wherein the processor 1001 and the memory 1002 communicate with each other through the bus 1003.

[0077] The processor 1001 is used to call program instructions in the memory 1002 to execute the methods provided in the above-described method embodiments, such as: obtaining a requirement generation request for the target underwater equipment; in response to the requirement generation request, extracting Proxy Port, Value Property, and all Part Property from the SysML design model of the underwater equipment; generating functional requirements for the next system level of the underwater equipment based on the Part Property; generating interface requirements for the next system level of the underwater equipment based on the Proxy Port; and generating performance requirements for the next system level of the underwater equipment based on the Value Property.

[0078] The processor 1001 can be an integrated circuit chip with signal processing capabilities. The processor 1001 can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the various methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor.

[0079] The memory 1002 may include, but is not limited to, random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), etc.

[0080] This embodiment discloses a computer program product, which includes a computer program stored on a non-transitory computer-readable storage medium. The computer program includes program instructions, and when the program instructions are executed by a computer, the computer can perform the methods provided in the above-described method embodiments, such as: obtaining a requirement generation request for a target underwater equipment; in response to the requirement generation request, extracting Proxy Port, Value Property, and all Part Properties from the SysML design model of the underwater equipment; generating functional requirements for the next system level of the underwater equipment based on the Part Properties; generating interface requirements for the next system level of the underwater equipment based on the Proxy Port; and generating performance requirements for the next system level of the underwater equipment based on the Value Property.

[0081] This embodiment provides a non-transitory computer-readable storage medium storing computer instructions that cause the computer to execute the methods provided in the above-described method embodiments, such as: obtaining a requirement generation request for a target underwater equipment; in response to the requirement generation request, extracting a Proxy Port, a Value Property, and all Part Properties from the SysML design model of the underwater equipment; generating functional requirements for the next system level of the underwater equipment based on the Part Properties; generating interface requirements for the next system level of the underwater equipment based on the Proxy Port; and generating performance requirements for the next system level of the underwater equipment based on the Value Property.

[0082] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some communication interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0083] Furthermore, the units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0084] Furthermore, 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.

[0085] In this document, relational terms such as first and second are used only to distinguish one entity or operation from another entity or operation, without necessarily requiring or implying any such actual relationship or order between these entities or operations.

[0086] The above descriptions are merely preferred embodiments of this application, and the present invention is not limited to the above embodiments. It is understood that other improvements and variations directly derived or conceived by those skilled in the art without departing from the spirit and concept of the present invention should be considered to be included within the protection scope of the present invention.< / satisfy> < / refine> < / refine> < / satisfy> < / refine> < / satisfy> < / refine> < / refine>

Claims

1. A method for generating underwater equipment requirements based on SysML design elements, characterized in that, include: Obtain the requirement generation request for the target underwater equipment; In response to the requirement generation request, the proxy port, value property, and all part properties used as part types are extracted from the SysML design model of the underwater equipment. Generate the functional requirements for the next system level corresponding to the underwater equipment based on the Part Property; The interface requirements for the next system level corresponding to the underwater equipment are generated based on the Proxy Port. The performance requirements for the next system level corresponding to the underwater equipment are generated based on the Value Property.

2. The underwater equipment requirements generation method based on SysML design elements according to claim 1, characterized in that, The step of generating the functional requirements for the next system level corresponding to the underwater equipment based on the Part Property includes: For each Part Property of the underwater equipment, determine the Call Behavior Action that has an allocation association with the Part Property; Obtain the name of the Behavior invoked by the Call Behavior Action, and generate the corresponding underwater equipment functional requirements for the Part Property based on the name.

3. The underwater equipment requirements generation method based on SysML design elements according to claim 1, characterized in that, The step of generating the interface requirements for the next system level corresponding to the underwater equipment based on the Proxy Port includes: For each of the underwater equipment's Proxy Ports, obtain the InterfaceBlock corresponding to the Proxy Port; Use the name of the Interface Block as the interface requirement name; Obtain the direction attribute of the Flow Property in the Interface Block, and use the direction attribute as the interface direction; Obtain the connection relationship Connector of the Proxy Port, and check whether both ends of the Connector are PartProperty. If so, use the type name of the Part Property of the other end of the Connector as the interface interaction object; otherwise, skip the Connector. Based on the interface requirement name, the interface direction, and the interface interaction object, generate the underwater equipment interface requirements corresponding to the Proxy Port.

4. The underwater equipment requirements generation method based on SysML design elements according to claim 1, characterized in that, The step of generating the performance requirements for the next system level corresponding to the underwater equipment based on the Value Property includes: For each of the underwater equipment's Value Property, the name attribute of the Value Property is used as the name of the performance requirement; Use the defaultValue property of the Value Property as the required value; Use the 'unit' attribute of the required value as the unit of the required value; The underwater equipment performance requirements are generated based on the name of the performance requirement, the requirement value, and its unit.

5. The underwater equipment requirements generation method based on SysML design elements according to claim 1, characterized in that, After generating the functional requirements, interface requirements, and performance requirements, the method further includes: Establish the traceability relationship between the aforementioned functional requirements, interface requirements, and performance requirements, and the source design elements of underwater equipment at the previous system level.

6. The underwater equipment requirements generation method based on SysML design elements according to claim 5, characterized in that, The steps for establishing the traceability relationship between the aforementioned functional requirements and the source design elements of underwater equipment at the higher system level include: Obtain the identifier corresponding to the underwater equipment behavior element of the previous system level; The identifiers are matched with the generated functional requirements to obtain the target functional requirements; Establish a traceability relationship between the behavioral elements and the target functional requirements.

7. The underwater equipment requirements generation method based on SysML design elements according to claim 5, characterized in that, The steps for establishing the traceability relationship between the interface requirements and the source design elements of underwater equipment at the higher system level include: Get the name of the Interface Block corresponding to the Proxy Port of the underwater equipment in the previous system level; The name is matched with the generated interface requirements to obtain the target interface requirements; Establish a traceability relationship between the Proxy Port element and the target interface requirement.

8. The underwater equipment requirements generation method based on SysML design elements according to claim 5, characterized in that, The steps for establishing the traceability relationship between the performance requirements and the source design elements of underwater equipment at the higher system level include: Retrieve the Value Property and Constraint Block of the underwater equipment from the previous system level; The name of the Value Property is matched with the generated performance requirements to obtain the first target performance requirement; Establish a traceability relationship between the Value Property and the first target performance requirement; Parse the constraint parameters and constraint expressions in the Constraint Block; The constraint expression is converted into requirement text, and the requirement text and / or constraint parameters are matched with the performance requirement to obtain the second target performance requirement; Establish a traceability relationship between the Constraint Block and the second target performance requirement.

9. The underwater equipment requirements generation method based on SysML design elements according to any one of claims 5-8, characterized in that, After obtaining the traceability relationship, the method further includes: A traceability matrix for underwater equipment requirements is generated based on the aforementioned traceability relationships. The traceability matrix is ​​then visualized.

10. An underwater equipment requirements generation device based on SysML design elements, characterized in that, include: The request acquisition module is used to acquire the requirement generation request for the target underwater equipment; The element extraction module is used to extract the proxy port, value property, and all PartProperty used as part types from the SysML design model of the underwater equipment in response to the requirement generation request. The functional requirements generation module is used to generate the functional requirements of the next system level corresponding to the underwater equipment based on the Part Property. The interface requirement generation module is used to generate the interface requirements of the underwater equipment at the next system level based on the Proxy Port. The performance requirement generation module is used to generate the performance requirements of the underwater equipment for the next system level based on the Value Property.

Images