Automobile design data management method, device, equipment, medium and product

Abstract

The invention discloses an automobile design data management method and device, equipment, a medium and a product, and relates to the field of automobile design, and the method comprises the steps: obtaining a demand model and a simulation model corresponding to each assembly of automobile product engineering; the demand model comprises all demand entries arranged according to a hierarchical relationship; the simulation model comprises all model simulation projects arranged according to a hierarchical relationship; analyzing the demand model and the simulation model corresponding to the assembly by adopting an OSLC technology to obtain a demand analysis chart and a model design chart corresponding to the assembly; nodes of the demand analysis graph corresponding to the assembly are demand entries corresponding to the assembly; nodes of the model design drawings corresponding to the assemblies are names and parameter information of model simulation projects corresponding to the assemblies; associating nodes in the demand analysis diagram corresponding to the assembly with nodes in the model design diagram to obtain an association diagram corresponding to the assembly; and the association graph is stored in a relational database. According to the method, unified management can be carried out on model data of different assemblies.

Description

Technical Field

[0001] The present application relates to the field of automobile design, and in particular to an automobile design data management method, device, equipment, medium and product. Background Art

[0002] During the automotive product engineering design phase, multiple steps are required, including general layout design, assembly design, and vehicle verification. During the assembly design phase, each component is usually distributed to various departments for design and development. Based on the different characteristics of each assembly, such as the different engine and chassis structures, different design tools are used. Existing automotive design data management methods are unable to uniformly manage the model data of different assemblies. Summary of the Invention

[0003] The purpose of this application is to provide an automobile design data management method, device, equipment, medium and product, which can uniformly manage model data of different assemblies.

[0004] To achieve the above objectives, this application provides the following solutions.

[0005] In the first aspect, the present application provides a method for automobile design data management, including: obtaining the demand model corresponding to each assembly in the automobile product engineering demand analysis stage and the simulation model corresponding to each assembly in the design scheme stage; the demand model includes all demand items arranged in a hierarchical relationship; the simulation model includes all model simulation projects arranged in a hierarchical relationship.

[0006] For any assembly, the Open Service for Lifecycle Collaboration (OSLC) technology is used to parse the demand model and simulation model corresponding to the assembly to obtain the demand analysis diagram and model design diagram corresponding to the assembly; the nodes of the demand analysis diagram corresponding to the assembly are the demand items corresponding to the assembly; the nodes of the model design diagram corresponding to the assembly are the name and parameter information of the model simulation project corresponding to the assembly.

[0007] The nodes in the demand analysis diagram corresponding to the assembly and the nodes in the model design diagram corresponding to the assembly are associated to obtain an association diagram corresponding to the assembly.

[0008] The association diagrams corresponding to each assembly are stored in a relational database.

[0009] Optionally, after storing the association graph corresponding to each assembly in the relational database, the method further includes: for any assembly, obtaining the changed node corresponding to the assembly in the relational database in real time.

[0010] The relational database is traversed to obtain nodes associated with a target node; the target node is the changed node corresponding to the assembly.

[0011] The producer sends a notification to the consumer, informing the consumer to modify the model simulation project corresponding to the node associated with the target node, and returns to the step of using OSLC technology to parse the demand model corresponding to the assembly and the simulation model corresponding to the assembly to obtain the demand analysis diagram corresponding to the assembly and the model design diagram corresponding to the assembly; the producer is the person in charge of the target node; the consumer is the person in charge of the node associated with the target node.

[0012] Optionally, the automobile design data management method further includes: visualizing an association graph associated with the target node and a model simulation project corresponding to a node associated with the target node.

[0013] Optionally, traversing the relational database to obtain the nodes associated with the target node specifically includes: using a search algorithm to traverse the relational database to obtain the nodes associated with the target node.

[0014] In the second aspect, the present application provides an automobile design data management device, including: a first acquisition module, used to obtain the requirement model corresponding to each assembly in the automobile product engineering requirement analysis stage and the simulation model corresponding to each assembly in the design scheme stage; the requirement model includes all requirement items arranged in a hierarchical relationship; the simulation model includes all model simulation projects arranged in a hierarchical relationship.

[0015] The OSLC service parsing component is used to parse the demand model and simulation model corresponding to any assembly using OSLC technology to obtain the demand analysis diagram and model design diagram corresponding to the assembly; the nodes of the demand analysis diagram corresponding to the assembly are the demand items corresponding to the assembly; the nodes of the model design diagram corresponding to the assembly are the name and parameter information of the model simulation project corresponding to the assembly.

[0016] The graph data connection analysis component is used to associate the nodes in the demand analysis graph corresponding to the assembly and the nodes in the model design graph corresponding to the assembly to obtain the association graph corresponding to the assembly, and store the association graph corresponding to each assembly in a relational database.

[0017] Optionally, the automobile design data management device further includes: a second acquisition module, configured to acquire, for any assembly, in real time the changed node corresponding to the assembly in the relational database.

[0018] The tracing component is used to traverse the relational database to obtain nodes associated with a target node; the target node is the changed node corresponding to the assembly.

[0019] The notification component is used for the producer to send a notification to the consumer, notifying the consumer to modify the model simulation project corresponding to the node associated with the target node and execute the OSLC service parsing component; the producer is the person in charge of the target node; the consumer is the person in charge of the node associated with the target node.

[0020] Optionally, the automobile design data management device further includes: a front-end visualization component for visualizing an association graph associated with a target node and a model simulation project corresponding to a node associated with the target node.

[0021] In a third aspect, the present application provides a computer device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement any of the above-mentioned methods for managing automotive design data.

[0022] In a fourth aspect, the present application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements any of the above-mentioned methods for managing automobile design data.

[0023] In a fifth aspect, the present application provides a computer program product, comprising a computer program, which, when executed by a processor, implements any of the above-mentioned methods for managing automobile design data.

[0024] According to the specific embodiments provided in the present application, the present application has the following technical effects: the present application provides an automobile design data management method, device, equipment, medium and product, which uses OSLC technology to parse the demand model and simulation model corresponding to the assembly to obtain the demand analysis diagram and model design diagram corresponding to the assembly; associate the nodes in the demand analysis diagram corresponding to the assembly and the nodes in the model design diagram corresponding to the assembly to obtain the association diagram corresponding to the assembly; store the association diagram corresponding to each assembly in a relational database, and parse the demand model and simulation model into a unified graph structure by using OSLC technology, and store the association diagram in the relational database, thereby avoiding the problem of being unable to uniformly manage the model data of different assemblies due to the different characteristics of each assembly and the different design tools used. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0026] Figure 1 Develop and design a flow chart for vehicle performance.

[0027] Figure 2 This is a flow chart of a method for managing automobile design data provided in one embodiment of the present application.

[0028] Figure 3 A diagram showing the visualization of a Model-Based Systems Engineering (MBSE) model.

[0029] Figure 4 A flow chart showing how to use OSLC technology to parse the demand model and simulation model corresponding to the assembly and obtain the association diagram.

[0030] Figure 5 A schematic diagram of the storage format of the association graph.

[0031] Figure 6 This is a diagram of the notification process.

[0032] Figure 7 Design diagram for the message notification component.

[0033] Figure 8 This is a schematic diagram of the message queue.

[0034] Figure 9 This is a structural diagram of an automobile design data management device provided in one embodiment of the present application.

[0035] Figure 10 A schematic diagram of the structure of a computer device provided in one embodiment of the present application. DETAILED DESCRIPTION

[0036] The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0037] In order to make the above-mentioned purposes, features and advantages of the present application more obvious and easy to understand, the present application is further described in detail below with reference to the accompanying drawings and specific implementation methods.

[0038] In the design of a complete vehicle, the top-level task indicators are often gradually decomposed into the task indicators of the assembly system and components. Different departments carry out modeling, design and verification according to the assembly task indicators. Finally, each perfected model is matched with the task indicators one by one to ensure that the assembly task indicators are responded to, thereby ensuring that the top-level task indicators are achieved. Figure 1 As shown, the vehicle performance requirement index system usually covers multiple core areas such as power, economy, and safety, and each area is further subdivided into multi-level sub-item indicators. For example, the power index system includes key sub-items such as maximum speed, acceleration capability, and maximum climbing grade, and the maximum speed index can be decomposed into multiple sub-indicators such as power system performance, control system parameters, and vehicle matching optimization. Each sub-indicator must be implemented and verified through corresponding technical tasks to ensure that it meets the design requirements, thereby achieving the overall achievement of the vehicle performance requirement indicators. Based on this, the embodiment of the present application provides a method for managing automobile design data, such as Figure 2 As shown, the automobile design data management method includes the following steps 201 to 204, wherein.

[0039] Step 201: Obtain the demand model corresponding to each assembly in the automotive product engineering demand analysis phase and the simulation model corresponding to each assembly in the design solution phase; the demand model includes all demand items arranged in a hierarchical relationship; the simulation model includes all model simulation projects arranged in a hierarchical relationship.

[0040] Step 202: For any assembly, Figure 4 As shown, OSLC technology is used to parse the requirements model and simulation model corresponding to the assembly, resulting in a requirements analysis diagram and a model design diagram corresponding to the assembly. The nodes in the requirements analysis diagram represent the requirements items corresponding to the assembly, while the nodes in the model design diagram represent the names and parameter information of the model simulation projects corresponding to the assembly. This parsing using OSLC technology yields unified data for easier management.

[0041] Step 203: Associate the nodes in the demand analysis diagram corresponding to the assembly with the nodes in the model design diagram corresponding to the assembly to obtain the association diagram corresponding to the assembly, i.e. Figure 4 The analysis and design model in . Specifically, it is implemented as MBSE model.

[0042] Step 204: Store the association graph corresponding to each assembly into a relational database.

[0043] OSLC technical specifications are primarily used to address the integration of various tools throughout the lifecycle. OSLC technical specifications consist of core specifications and domain specifications. Core specifications describe core integration technologies and general concepts. Domain specifications are written based on core specifications and extend specific engineering domains. Using OSLC technical specifications ensures that integrators can understand data from different domains while accessing data. Therefore, implementing steps 201 to 204 above enables unified management of model data for different assemblies.

[0044] This application is based on MBSE. The system engineering lifecycle model is composed of different domain models, and there are associations between the entities and instances of each domain model. In addition, there are also various associations between the entities and instances in the domain model. Therefore, the system engineering lifecycle model is essentially a network composed of model entities and model relationships, and the graph data structure is the most suitable data structure to describe this network. The model entities are the domain models of each field, the model instances are the graph nodes in the domain model, and the model relationships are the edges of the graph. Figure 4 As shown, the requirement model, analysis and design model, and simulation model represent domain model entities. The requirement items in the requirement model, the requirement analysis diagram in the analysis and design model, the model design diagram, the model simulation project of the simulation model, etc. represent instances in the domain model. There will be different association relationships between instances. For example, between domain models, a requirement model will correspond to a requirement analysis diagram, and a model design diagram will correspond to a simulation model. These associations constitute the relationship between domain models. Within the domain model, for example, each requirement analysis diagram will have a model design diagram that meets its requirements. Such associations constitute the relationship within the domain model. Through a graph structure similar to this, all domain models and heterogeneous data in the system engineering life cycle and their complex association relationships can be described using a graph, i.e., steps 201 to 203 of this application.

[0045] To store a graph structure in a database, it is necessary to model the data format for graph structure storage. To store different points, it is necessary to distinguish the points, so each point needs a unique ID to describe it. Edges are used to connect points, indicating the relationship or behavior between two points. To save an edge, it is necessary to record its starting point and end point as well as the relationship between the two points. Therefore, in another exemplary embodiment of the present application, the association graph corresponding to each assembly is stored in a relational database, such as Figure 5 As shown, the following rules are followed: Figure 5 As shown in (a), the node store stores the node ID and node type of each node. The node type can be a name and parameter information or a requirement entry, which is used to associate different attributes.

[0046] like Figure 5 As shown in (b), the edge storage stores the node IDs of each edge's starting and ending points, as well as the edge type, which can be either an outgoing or incoming edge. When the edge type is an outgoing edge, the edge type is a number greater than 0, the node ID of the starting point represents the ID of the source node, and the node ID of the ending point represents the ID of the destination node. When the edge type is an incoming edge, the edge type is a number less than 0, the node ID of the starting point represents the ID of the destination node, and the node ID of the ending point represents the ID of the source node.

[0047] Because top-level task indicators often change during the traditional design and development phase, leading to changes in corresponding assembly and component models, changes to upstream MBSE nodes often fail to be promptly communicated to their downstream counterparts. Information interruptions or lack of transparency lead to delays or ineffective downstream work, inadvertently increasing costs and slowing project progress. Promptly notifying each assembly's responsible person is both crucial and challenging. Furthermore, timely collection of model modification status and feedback from responsible persons is essential to ensuring the achievement of top-level task indicators after changes. Therefore, providing fast and timely communication information to promptly notify relevant responsible persons of upstream changes and achieve MBSE process traceability is crucial. By storing and associating system lifecycle models in a graph format, downstream nodes associated with upstream nodes can be quickly identified and notified. Therefore, in another exemplary embodiment of the present application, after storing the associated graphs corresponding to each assembly in a relational database, the following steps are further included: for each assembly, real-time acquisition of the changed nodes corresponding to the assembly from the relational database is performed. The relational database is traversed to obtain nodes associated with a target node; the target node is the node corresponding to the changed assembly.

[0048] The producer sends a notification to the consumer, informing the consumer to modify the model simulation project corresponding to the node associated with the target node, and returns to the step of using OSLC technology to parse the demand model corresponding to the assembly and the simulation model corresponding to the assembly to obtain the demand analysis diagram corresponding to the assembly and the model design diagram corresponding to the assembly; the producer is the person in charge of the target node; the consumer is the person in charge of the node associated with the target node. Figure 6 As shown, Figure 6 Part (a) shows the MBSE model traceability diagram. When a requirement changes, the system will find its associated model through association analysis, and then find the person in charge of the corresponding model and notify them. Figure 6 Part (b) shows the MBSE model traceability flow chart. When a requirement item changes, the associated model first changes its state. This notifies the corresponding model owner, who then modifies the model based on the changed requirement item and re-updates the model state, forming a closed loop. In this embodiment, when MBSE task indicators change during the R&D process, downstream models that require changes are promptly notified based on the associated relationships, facilitating timely updates of the associated models based on the changes. Once the model modifications are complete, the data source is re-updated, allowing the task owner to review the overall status in a timely manner.

[0049] Conveniently viewing the hierarchical relationships of top-level task indicators and their corresponding models facilitates overall design progress and management control. Based on this, in another exemplary embodiment of the present application, the automotive design data management method further includes visualizing the association graph associated with the target node and the model simulation project corresponding to the node associated with the target node. Specifically, visualization is achieved through the MBSE model.

[0050] In another exemplary embodiment of the present application, traversing the relational database to obtain the nodes associated with the target node is specifically: using a search algorithm to traverse the relational database to obtain the nodes associated with the target node.

[0051] In another exemplary embodiment of the present application, a search algorithm is used to traverse the relational database to obtain nodes associated with the target node, specifically: using a breadth-first search algorithm (Breadth First Search, BFS) or a depth-first search algorithm (Depth First Search, DFS) to traverse and find downstream nodes associated with the changed node.

[0052] The breadth-first search algorithm is similar to the tree traversal by level. Its basic idea is to first visit the starting point v i , then visit v i All unvisited adjacent points v i1 ,v i2 ,···,v it , and mark them as visited, and then i1 ,v i2 ,···,v it , visit all nodes that have not been visited by each node in turn, and mark them as visited. And so on, until all nodes and the starting point v are visited. i Until all nodes connected by paths have been visited.

[0053] The steps of breadth-first search algorithm are as follows.

[0054] Step 1.1: Mark the starting node vi as visited and add it to the queue.

[0055] Step 2.1: Take a node from the queue as the current node and mark it as the current node.

[0056] Step 3.1: Traverse all neighbor nodes of the current node and perform the following operations for each neighbor node: If the neighbor node has not been visited, mark it as visited and add it to the queue.

[0057] Step 4.1: After completing the traversal of the neighbor nodes of the current node, the current node is dequeued.

[0058] Step 5.1: Repeat Step 2.1-Step 4.1 until the queue is empty.

[0059] The depth-first search algorithm is a recursive search process. Its basic idea is to first visit the starting point v i Then select a v i Unvisited neighboring point v j , with v j Continue depth-first search for new starting points until all nodes in the graph have been visited.

[0060] The steps of the depth-first search algorithm are as follows.

[0061] Step A: Set the starting node v i Mark as visited.

[0062] Step B: For v i For each unvisited neighbor node of , mark the neighbor node as unvisited.

[0063] Step C: Recursively call the depth-first search algorithm with the neighbor node as the new starting node.

[0064] Step D: Repeat step B until all neighbor nodes of the current node are visited.

[0065] In another exemplary embodiment of the present application, the producer sends a notification to the consumer, such as Figure 7 As shown in the figure, using message queue technology, producers send notifications to a message queue, and consumers receive the messages and act on the notifications. Message queues enable asynchronous communication and decouple system components. By sending messages to a queue, they achieve message buffering, asynchronous processing, and reliable delivery. Message queues provide an asynchronous communication mechanism for delivering messages in distributed systems.

[0066] The core principles of message queues include the following aspects.

[0067] Queues: Message queues use a queue data structure to store messages. A queue is a first-in, first-out data structure that ensures message order. New messages are added to the end of the queue, and consumers retrieve messages from the head of the queue.

[0068] Message queue persistence: Message queue persistence prevents message loss during system failures or downtime. Persistence is achieved by storing messages on persistent storage. Even if the message queue crashes or restarts, messages already stored on persistent storage can be recovered, ensuring reliable message delivery.

[0069] Message queue switch routing: The message queue switch determines the path or destination routing mechanism from the producer to the consumer, which is generally divided into direct matching and topic matching. In direct matching, messages are directly matched with queues or consumers through the specified routing key. When a message's routing key exactly matches the binding key of a queue or consumer, the message is sent to that queue or consumer. Topic matching allows the use of wildcards to match the routing key of messages. Common wildcards include " " (matches one word) and "#" (matches zero or more words). The routing key of a message can be a hierarchical structure consisting of multiple words. Topic matching routes messages to queues or consumers that meet the matching rules by matching each word in the routing key.

[0070] Exception handling mechanism: Message queues usually use the following mechanisms to deal with various failure conditions.

[0071] The confirmation mechanism is used to ensure that the message is correctly deleted from the queue after being processed by the consumer. After successfully processing the message, the consumer sends a confirmation message to the message queue, and the message queue then marks the message as consumed and removes it from the queue.

[0072] A message queue provides a retry mechanism when a consumer fails to successfully process a message. This mechanism places the message back into the queue for further processing. You can control the message retry behavior by setting parameters such as the maximum number of retries and the retry interval.

[0073] Dead letter queues are used to store messages that cannot be processed by consumers. When a message cannot be successfully processed after a certain number of retries, the message queue moves the message to the dead letter queue for further analysis and processing. Dead letter queues can be used to identify failed messages and take appropriate remedial measures.

[0074] like Figure 8 As shown in the figure, after the producer sends a message, the message queue will be sent to one or more matching queues according to the routing algorithm configured in the switch. The consumer obtains the message from the relevant topic it subscribes to or the queue that matches it and then processes the message.

[0075] Based on the same inventive concept, embodiments of the present application also provide an automobile design data management device for implementing the aforementioned automobile design data management method. The solution provided by this device is similar to the solution described in the aforementioned method. Therefore, the specific limitations in one or more of the following embodiments of the automobile design data management device can be found in the above-described limitations of the automobile design data management method and will not be further elaborated here.

[0076] In an exemplary embodiment, Figure 9 As shown, an automobile design data management device is provided, including: a first acquisition module, used to obtain the demand model corresponding to each assembly in the automobile product engineering demand analysis stage and the simulation model corresponding to each assembly in the design scheme stage; the demand model includes all demand items arranged in a hierarchical relationship; the simulation model includes all model simulation projects arranged in a hierarchical relationship.

[0077] The OSLC service parsing component is used to parse the demand model and simulation model corresponding to any assembly using OSLC technology to obtain the demand analysis diagram and model design diagram corresponding to the assembly; the nodes of the demand analysis diagram corresponding to the assembly are the demand items corresponding to the assembly; the nodes of the model design diagram corresponding to the assembly are the name and parameter information of the model simulation project corresponding to the assembly.

[0078] The graph data connection analysis component is used to associate the nodes in the demand analysis graph corresponding to the assembly and the nodes in the model design graph corresponding to the assembly to obtain the association graph corresponding to the assembly, and store the association graph corresponding to each assembly in a relational database.

[0079] As an optional implementation, the automobile design data management device further includes: a second acquisition module, configured to acquire, for any assembly, in real time the changed node corresponding to the assembly in the relational database.

[0080] The tracing component is used to traverse the relational database to obtain nodes associated with a target node; the target node is the changed node corresponding to the assembly.

[0081] The notification component is used by producers to send notifications to consumers, instructing them to modify the model simulation project corresponding to the node associated with the target node and execute the OSLC service resolution component. The producer is the owner of the target node, and the consumer is the owner of the node associated with the target node. Specifically, the notification component uses message queue technology to develop message notification components. When a notification-triggering event occurs, the producer provides the notification content and sends it to the message queue. The consumer receives the message from the message queue and executes the message notification.

[0082] As an optional embodiment, the automotive design data management device further includes a front-end visualization component for visualizing the association graph associated with the target node and the model simulation projects corresponding to the nodes associated with the target node. Specifically, when displaying the association graph associated with target node A' in the requirements analysis graph, the graph data connection analysis component is used to query node A' in the requirements analysis graph from the database. Based on this node A', the nodes in the model design graph associated with it are then retrieved from all stored association graphs, as well as the association relationships (i.e., edge relationships) between node A' and the selected nodes in the model design graph. The parent, child, and sibling nodes of node A' are then retrieved. Finally, this information is integrated and sent to the front-end visualization component for drawing and displaying the overall association graph. The traceability component sends the nodes associated with the target node to the front-end visualization component, which then highlights the model simulation projects corresponding to the nodes associated with the target node.

[0083] Complex product design scenarios often require the use of MBSE tools for multi-domain forward design. The MBSE toolchain platform aims to provide MBSE toolchain users with an unprecedented graphical, visual management, and interactive experience. The MBSE toolchain platform not only stores and manages MBSE model sources and relationships, but also uses an intuitive and easy-to-understand graphical interface to clearly visualize complex model relationships. The MBSE toolchain platform also integrates heterogeneous data sources from various MBSE tools, which were previously dispersed and difficult to manage, into a unified platform, graphically displaying the connections and interactions between data. Users can easily create, edit, and link models with simple drag-and-drop operations, significantly improving work efficiency. Furthermore, the MBSE toolchain platform should feature powerful visualization capabilities that display model status and changes in real time, allowing users to stay informed of the latest model developments. This visual management approach not only reduces errors but also facilitates smoother collaboration across teams, improving overall work quality. In practice, the aforementioned automotive design data management device resides within the MBSE tool chain platform. When designing a complete vehicle, engineers typically follow a systematic process, starting with top-level objectives and then gradually breaking them down into specific objectives for each assembly system and component. First, system engineers determine the vehicle's top-level objectives, including performance metrics such as range and fuel economy per 100 kilometers. Using requirements design software, they work with engineers from each assembly to decompose these top-level objectives into the objectives for each assembly. The engineers from each assembly then decompose these objectives into the objectives for each component. Each assembly engineer also collaborates with the model development engineers within their department to determine the interfaces and integration methods between assemblies. Ultimately, they develop a preliminary, high-level design plan. During this process, system engineers can create MBSE projects within the MBSE tool chain platform based on vehicle requirements, edit project descriptions, and delete unnecessary projects. The requirements design software is integrated with the MBSE tool chain platform, and the requirements projects, tasks, and requirements items can all be displayed on the MBSE tool chain platform as data sources. After the model development engineer obtains the task indicators for which he is responsible, he uses the system simulation software to build the corresponding model. The system simulation software is also integrated with the MBSE tool chain platform, and resources such as model projects, model components, interfaces, parameters, and files can also be displayed on the MBSE tool chain platform as data sources. Each assembly engineer will establish an association relationship between the requirements items for which he is responsible and the models for which his department is responsible, and can also establish an association relationship between models from different departments. These association relationships are stored synchronously on the MBSE tool chain platform, making it convenient for system engineers and individual engineers to confirm and review them.During the overall design process, requirement items will also be changed according to customer requirements or actual conditions. When the status of a requirement item changes, the MBSE tool chain platform will immediately set the associated model to a pending change status and notify the associated model owner of the change content, helping the model development engineer to modify the model in a timely manner. After the modification is completed, the relevant model owner can change the model status to completed, forming a closed-loop change. In addition, the MBSE tool chain platform can also be opened directly in the system simulation software, and requirement items and associated relationships can be viewed directly in the operating environment of the system simulation software without switching systems. This helps engineers quickly build relationships and provides engineers with an efficient, intuitive, easy-to-maintain, and automated platform, enabling them to more conveniently monitor the progress of the entire design process and manage it in detail. This management method not only improves design efficiency, but also ensures product quality and design reliability.

[0084] For automotive product engineering chief engineers and sub-task engineers, integrating and managing different design and simulation tools remains a significant challenge. While traditional offline document-based management models can achieve a certain degree of integration between tools, maintenance is cumbersome and unintuitive. Under this model, data updates, synchronization, and error troubleshooting require significant time and effort, significantly increasing the burden on engineers. Furthermore, with the continuous expansion and update of design and simulation tools, the complexity and difficulty of this management model continue to increase, making it difficult for engineers to cope. The MBSE model can be visually applied in the following scenarios: Scenario Instance Management: During the R&D process, different scenario instances are created based on different design requirements. This effectively organizes and isolates requirements and models, grouping tasks related to the same scenario requirements together to facilitate management and maintenance, improving work efficiency. Model Relationship Management: During the R&D process, based on scenario design ideas, relationships between compatible data sources are conveniently created and managed. This structured approach to data source connection management makes scenarios more intuitive, easier to understand, and easier to implement. Single-point tool access: It can also be connected to the corresponding scenario in the MBSE single-point design tool to achieve seamless connection between the model in the single-point tool and the task requirements in the MBSE digital thread scenario, making the interaction between the model and the task requirements more efficient. Figure 3As shown, this application uses MBSE model visualization to facilitate the management, data association, and interaction of various source data within the MBSE tool chain, presenting them graphically. By building MBSE model visualization and association capabilities, the goal is to provide MBSE tool chain users with an unprecedented graphical, visual management, and interactive experience. This not only enables the storage and management of MBSE model sources and relationships, but also provides a clear overview of complex model relationships through an intuitive and easy-to-understand graphical interface. MBSE model visualization and association capabilities integrate previously dispersed and difficult-to-manage heterogeneous data sources from various MBSE tools into a unified platform, graphically displaying the associations and interactions between data. Users can easily create, edit, and associate models with simple drag-and-drop and clicks, significantly improving work efficiency. Furthermore, MBSE model visualization displays model status and changes in real time, allowing users to stay informed of the latest model developments. This visual management approach not only reduces errors but also facilitates smoother collaboration across teams, improving overall work quality.

[0085] The workflow of the automotive design data management device provided in this application is as follows: the OSLC service parsing component interacts with the read interface of the OSLC service set to parse the demand model and simulation model. The graph data connection analysis component performs correlation operations on the parsed results to obtain a correlation graph, stores the correlation graph in the database, and returns the correlation graph associated with the target node in the database to the front-end visualization component for correlation visualization. The traceability component traverses the database to obtain the nodes associated with the target node and returns the node ID associated with the target node to the front-end visualization component. The front-end visualization component highlights the model simulation project corresponding to the node associated with the target node and calls the notification component to notify the relevant person in charge.

[0086] In an exemplary embodiment, a computer device is provided. The computer device may be a server or a terminal. The internal structure diagram thereof may be as follows: Figure 10As shown. The computer device includes a processor, a memory, an input / output interface (Input / Output, abbreviated as I / O) and a communication interface. The processor, memory and input / output interface are connected through a system bus, and the communication interface is connected to the system bus through the input / output interface. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and computer program in the non-volatile storage medium. The database of the computer device is used to store automobile design data management data. The input / output interface of the computer device is used to exchange information between the processor and an external device. The communication interface of the computer device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, a method for managing automobile design data is implemented.

[0087] Those skilled in the art will understand that Figure 10 The structure shown in the figure is merely a block diagram of a portion of the structure related to the solution of the present application and does not constitute a limitation on the computer device to which the solution of the present application is applied. A specific computer device may include more or fewer components than shown in the figure, or combine certain components, or have a different component arrangement. In an exemplary embodiment, a computer device is provided, including a memory and a processor. The memory stores a computer program, and the processor implements the above-mentioned method embodiments when executing the computer program.

[0088] In an exemplary embodiment, a computer-readable storage medium is provided, storing a computer program, which implements the above-mentioned method embodiments when executed by a processor.

[0089] In an exemplary embodiment, a computer program product is provided, including a computer program. When the computer program is executed by a processor, the above method embodiments are implemented.

[0090] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with relevant regulations.

[0091] Those skilled in the art will appreciate that all or part of the processes in the above-mentioned embodiments can be implemented by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the above-mentioned embodiments. In particular, any reference to memory, database, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM may be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM).

[0092] The databases involved in the various embodiments provided herein may include at least one of a relational database and a non-relational database. Non-relational databases may include, but are not limited to, distributed databases based on blockchains. The processors involved in the various embodiments provided herein may include, but are not limited to, general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic units, data processing logic units based on quantum computing, and the like.

[0093] The technical features of the above embodiments can be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0094] This document uses specific examples to illustrate the principles and implementation methods of this application. The description of the above examples is only intended to help understand the method and core concept of this application. At the same time, for those skilled in the art, based on the concept of this application, there may be changes in the specific implementation methods and application scope. In summary, the content of this specification should not be understood as limiting this application.

Claims

1. A method for managing automobile design data, characterized in that: The automobile design data management method includes: Obtain the demand model corresponding to each assembly in the automotive product engineering demand analysis phase and the simulation model corresponding to each assembly in the design phase; the demand model includes all demand items arranged in a hierarchical relationship; the simulation model includes all model simulation projects arranged in a hierarchical relationship; For any assembly, OSLC technology is used to parse the demand model and simulation model corresponding to the assembly to obtain the demand analysis diagram and model design diagram corresponding to the assembly; the nodes of the demand analysis diagram corresponding to the assembly are the demand items corresponding to the assembly; the nodes of the model design diagram corresponding to the assembly are the names and parameter information of the model simulation projects corresponding to the assembly; Associating the nodes in the demand analysis diagram corresponding to the assembly with the nodes in the model design diagram corresponding to the assembly to obtain an association diagram corresponding to the assembly; The association diagrams corresponding to each assembly are stored in a relational database.

2. The automobile design data management method according to claim 1, characterized in that: After storing the association diagrams corresponding to each assembly in the relational database, the following steps are also included: For any assembly, obtain the changed nodes corresponding to the assembly in the relational database in real time; Traversing the relational database to obtain nodes associated with a target node; the target node is the changed node corresponding to the assembly; The producer sends a notification to the consumer, informing the consumer to modify the model simulation project corresponding to the node associated with the target node, and returns to the step of using OSLC technology to parse the demand model corresponding to the assembly and the simulation model corresponding to the assembly to obtain the demand analysis diagram corresponding to the assembly and the model design diagram corresponding to the assembly; the producer is the person in charge of the target node; the consumer is the person in charge of the node associated with the target node.

3. The automobile design data management method according to claim 2, characterized in that: The automobile design data management method further includes: visualizing an association graph associated with the target node and a model simulation project corresponding to a node associated with the target node.

4. The automobile design data management method according to claim 2, characterized in that: Traverse the relational database to obtain nodes associated with the target node, specifically: A search algorithm is used to traverse the relational database to obtain nodes associated with the target node.

5. An automobile design data management device, characterized in that: The automobile design data management device includes: The first acquisition module is used to obtain the demand model corresponding to each assembly in the automotive product engineering demand analysis phase and the simulation model corresponding to each assembly in the design phase; the demand model includes all demand items arranged in a hierarchical relationship; the simulation model includes all model simulation projects arranged in a hierarchical relationship; The OSLC service parsing component is used to parse the demand model and simulation model corresponding to any assembly using OSLC technology to obtain a demand analysis diagram and a model design diagram corresponding to the assembly; the nodes of the demand analysis diagram corresponding to the assembly are the demand items corresponding to the assembly; the nodes of the model design diagram corresponding to the assembly are the names and parameter information of the model simulation projects corresponding to the assembly; The graph data connection analysis component is used to associate the nodes in the demand analysis graph corresponding to the assembly and the nodes in the model design graph corresponding to the assembly to obtain the association graph corresponding to the assembly, and store the association graph corresponding to each assembly in a relational database.

6. The automobile design data management device according to claim 5, characterized in that: The automobile design data management device further includes: The second acquisition module is used to obtain, for any assembly, in real time the changed node corresponding to the assembly in the relational database; A tracing component, configured to traverse the relational database to obtain nodes associated with a target node; the target node being the node corresponding to the change of the assembly; The notification component is used for the producer to send a notification to the consumer, notifying the consumer to modify the model simulation project corresponding to the node associated with the target node and execute the OSLC service parsing component; the producer is the person in charge of the target node; the consumer is the person in charge of the node associated with the target node.

7. The automobile design data management device according to claim 6, characterized in that: The automobile design data management device further includes: a front-end visualization component for visualizing the association graph associated with the target node and the model simulation project corresponding to the node associated with the target node.

8. A computer device comprising: A memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the automobile design data management method according to any one of claims 1 to 4.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the automobile design data management method according to any one of claims 1 to 4 is implemented.

10. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the automobile design data management method according to any one of claims 1 to 4 is implemented.

Images