Industrial design data version management method, system, electronic device and storage medium

Abstract

The application provides an industrial design data version management method, system, electronic equipment and storage medium. The method comprises the following steps: mapping each design unit to a Git repository on a file system; storing the internal attributes of the design unit as an attribute file under the corresponding Git repository directory; the file name of the attribute file represents the attribute name, and the file content of the attribute file represents the attribute value; the assembly reference relationship between the design units is expressed through the submodule mechanism of Git; and the assembly hierarchical relationship between the design units is configured to be expressed through the nesting relationship of the directories in the file system. According to the architecture of "file as data", the attributes are stored in the file system in the form of files, the inconsistency problem caused by the separation of the relational database metadata and the entity file of the file server is eliminated, and the data consistency is jointly ensured by the file system and the Git atomic submission.

Description

Technical Field

[0001] This application relates to the field of industrial design data management, and more specifically, to an industrial design data version management method, system, electronic device, and storage medium. Background Technology

[0002] Currently, the file formats of widely used 3D CAD software in industry (such as CATIA, NX, Creo, and SolidWorks) are incompatible, and their internal data structures vary. In cross-enterprise collaboration, downstream suppliers often need to have multiple CAD software licenses or rely on neutral formats (such as STEP / IGES) for conversion. However, the conversion process can result in the loss of non-geometric information such as feature trees, parameter history, materials, and constraints, leading to the loss of data integrity and design intent. Summary of the Invention

[0003] In view of this, the purpose of this application is to provide an industrial design data version management method, system, electronic device and storage medium that can eliminate the dual-source inconsistency problem caused by the separation of relational database metadata and file server entity files in traditional solutions.

[0004] In a first aspect, embodiments of this application provide an industrial design data version management method, comprising: mapping each design unit to a Git repository on a file system; storing the internal attributes of the design unit as attribute files in the corresponding Git repository directory; wherein the filename of the attribute file represents the attribute name, and the file content of the attribute file represents the attribute value; expressing the assembly reference relationship between the design units through Git's submodule mechanism; wherein the assembly hierarchy relationship between the design units is configured to be expressed through the nesting relationship of directories in the file system.

[0005] In the above implementation process, the "file as data" architecture stores attributes as files in the file system, eliminating the dual-source inconsistency problem caused by the separation of relational database metadata and file server entity files in traditional solutions. The file system and Git atomic commits jointly ensure data consistency. In addition, each reusable design unit is treated as an independent Git repository, enabling industrial design data to naturally acquire complete Git native capabilities such as version tracking, branch management, and merge conflict handling, without the need for additional version management logic development.

[0006] In one embodiment, the design unit is configured to be split into entities and nodes; wherein the entity is configured as an independent Git repository for storing common attributes; and the node is configured as a submodule for storing location-specific attributes.

[0007] In the above implementation process, through Git Submodules and entity / node separation, the same standard part can be referenced by multiple assembly locations. Modifying the entity once synchronizes all reference locations, while the positional attributes (transformation matrices, etc.) of each node remain independent, avoiding file copying or complex database reference maintenance in traditional solutions. Furthermore, the standardized file system interface and AI Agent interface give the system extremely high openness and scalability, allowing it to seamlessly integrate into future intelligent design processes.

[0008] In one embodiment, it further includes: managing concurrent operations on the Git repository by multiple users through a server-side workspace.

[0009] In the above implementation process, by setting up a server-side fork workspace mechanism, the client does not need to install Git or download the complete repository. It can complete the editing and submission of design data only through the HTTP API. It supports access from lightweight environments such as web browsers and AIAgent, increasing the application scenarios of this method.

[0010] In one embodiment, managing concurrent operations on the Git repository by multiple users through a server-side workspace includes: responding to client edit requests through the server-side workspace manager and creating isolated server-side workspaces from the source Git repository; wherein the server-side workspace is configured to allow clients to read and write attribute files through a file operation interface; responding to commit commands to submit changes locally to the server-side workspace; and responding to push commands to push and merge the changes back to the source Git repository.

[0011] In the above implementation process, by setting up a server-side fork workspace mechanism, the client does not need to install Git or download the complete repository. It can complete the editing and submission of design data only through the HTTP API. It supports access from lightweight environments such as web browsers and AIAgent, increasing the application scenarios of this method.

[0012] In one embodiment, the relational database is configured to store index data, the object storage is configured to store Git objects and large industrial files, and the local cache is configured to store hot data of the active workspace; wherein, the large industrial files are stored in the object storage through the Git LFS pointer mechanism, and the Git repository only retains pointer files that point to the actual content in the object storage.

[0013] In the above implementation process, by setting up a three-tier storage architecture (i.e., relational database, object storage and large file, local cache) in conjunction with the Git LFS transparent pointer mechanism, it is possible to prevent Git repository from growing while maintaining the transparency of user operations, thus balancing storage efficiency and user experience.

[0014] In one embodiment, the native format files of various drafting software are stored as binary data files in the corresponding directory, and the design attributes extracted from the native format files are laid out as attribute files in the directory.

[0015] In the above implementation process, by uniformly mapping the native formats of various mainstream CAD software to a directory structure of "attribute file + binary data file", the differences between different CAD formats can be shielded, and upper-level applications do not need to be aware of the underlying format.

[0016] In one embodiment, the method further includes: providing a standard toolset conforming to the Model Context Protocol (MCP) through an AI Agent interface; wherein the AI ​​Agent interface encapsulates Git underlying operations with file operation semantics, and the AI ​​Agent interface is configured to operate on design data in a read-write file manner.

[0017] In the above implementation process, by encapsulating the underlying Git operations into file operation semantics, the AI ​​Agent can operate on industrial design data in a way that reads and writes files, which greatly reduces the integration threshold between AI and industrial design systems.

[0018] In one embodiment, the configuration further includes: performing configuration inheritance and incremental overriding step by step according to the global default configuration layer, the tenant enterprise configuration layer, the team configuration layer, and the project configuration layer; wherein, configuration changes at each level are stored with independent Git commit records; and the configuration merge chain is declared through the manifest.json file in each level directory.

[0019] In the above implementation process, the cross-tenant read-only standard data layer, combined with live / frozen dual-mode references, can ensure the consistency of standard data versions while allowing tenants to choose tracing strategies as needed.

[0020] In one embodiment, the method further includes: establishing a first target directory on top of the tenant-isolated business data; wherein the first target directory is configured to store national standard geometric tolerance tables and thread data from multiple CAD software programs; the business data of different tenants are physically isolated in a second target directory, and each tenant has an independent namespace and access control; the tenants reference standard data through multiple modes.

[0021] In the above implementation process, the cross-tenant read-only standard data layer, combined with live / frozen dual-mode references, can ensure the consistency of standard data versions while allowing tenants to choose tracing strategies as needed.

[0022] Secondly, embodiments of this application also provide an industrial design data version management system, comprising: a Git repository mapping layer for mapping each design unit to a Git repository on a file system; a file system abstraction layer for storing the internal attributes of the design unit as attribute files in the corresponding Git repository directory; wherein the filename of the attribute file represents the attribute name, and the file content of the attribute file represents the attribute value; and a relationship expression layer for expressing the assembly reference relationship between the design units through Git's submodule mechanism; wherein the assembly hierarchy relationship between the design units is configured to be expressed through the nesting relationship of directories in the file system.

[0023] Thirdly, embodiments of this application also provide an electronic device, including: a processor and a memory, wherein the memory stores machine-readable instructions executable by the processor, and when the electronic device is running, the machine-readable instructions are executed by the processor to perform the steps of the method described in the first aspect above, or any possible implementation of the first aspect.

[0024] Fourthly, embodiments of this application also provide a computer-readable storage medium storing a computer program that, when executed by a processor, performs the steps of the industrial design data version management method described in the first aspect or any possible implementation of the first aspect.

[0025] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, specific embodiments are described below in conjunction with the accompanying drawings. Attached Figure Description

[0026] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0027] Figure 1 A block diagram illustrating an electronic device provided in an embodiment of this application; Figure 2 A flowchart for industrial design data version management provided in this application embodiment; Figure 3 This is a schematic diagram illustrating the separation of entities and nodes provided in an embodiment of this application. Figure 4 A server-side workspace lifecycle state machine diagram provided for embodiments of this application; Figure 5 Example diagram of a file directory structure with attribute tiling provided in the embodiments of this application; Figure 6 A schematic diagram of the complete file system directory tree and configuration merging chain provided for embodiments of this application; Figure 7 This is a schematic diagram illustrating the unified mapping of multiple CAD formats provided in an embodiment of this application; Figure 8 This application provides a schematic diagram of the global standard data layer and tenant isolation directory tree in an embodiment. Figure 9 This application provides a schematic diagram of the functional modules of the industrial design data version management system. Detailed Implementation

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

[0029] In product development, a complete set of design data typically includes multiple types, such as 3D models (part geometry, assembly constraints), assembly structures (hierarchical relationships from assembly to parts), 2D engineering drawings (view projections, dimensioning), lightweight models, enterprise configurations (material libraries, tolerance tables), and industry standards. These data have strong interrelationships; for example, assemblies reference parts, engineering drawings reference 3D models, and modifying a part may require simultaneous updates to its engineering drawings and all assemblies that reference it.

[0030] Existing technical solutions for managing industrial design data have the following main shortcomings: 1. Separation of metadata and entity files can easily lead to data inconsistency; version management is weak, usually relying only on timestamps; the performance of assembly level queries decreases significantly with increasing level depth; and support for multiple CAD formats requires manual maintenance of mapping paths.

[0031] 2. The "checkout-lock" model limits the efficiency of parallel editing; the version engine is closed and cannot interoperate with standard Git and other general version control tools; the license fee is high; and it is strongly coupled with specific CAD formats.

[0032] 3. Frequent commits of binary CAD files can lead to a rapid increase in repository size; the common git diff command cannot perform industrially semantic comparisons of binary files; there is a lack of tenant or team-level isolation mechanisms; and there is no standardized interface for interaction with external AI programs.

[0033] In summary, none of the existing solutions provide an efficient and low-cost technical solution for unifying heterogeneous CAD data into versionable, collaboratively operable units.

[0034] In view of this, this application proposes an industrial design data version management method. Through a "file-as-data" architecture, attributes are stored as files in the file system, eliminating the inconsistency problem caused by the separation of relational database metadata and file server entity files in traditional solutions. The file system and Git atomic commits jointly ensure data consistency. Furthermore, each reusable design unit is treated as an independent Git repository, enabling industrial design data to naturally acquire complete Git native capabilities such as version tracking, branch management, and merge conflict handling, without requiring additional version management logic development.

[0035] To facilitate understanding of this embodiment, the electronic device that implements the industrial design data version management method disclosed in this application embodiment will first be described in detail.

[0036] like Figure 1 The diagram shown is a block illustration of an electronic device. The electronic device 100 may include a memory 111 and a processor 113. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the electronic device 100. For example, the electronic device 100 may also include components that are more... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0037] The aforementioned memory 111 and processor 113 are electrically connected to each other directly or indirectly to enable data transmission or interaction. For example, these components can be electrically connected to each other via one or more communication buses or signal lines. The aforementioned processor 113 is used to execute executable modules stored in the memory.

[0038] The memory 111 can be, 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. The memory 111 stores programs, and the processor 113 executes these programs upon receiving execution instructions. The methods executed by the electronic device 100 as defined in any embodiment of this application can be applied to the processor 113, or implemented by the processor 113.

[0039] The aforementioned processor 113 may be an integrated circuit chip with signal processing capabilities. The processor 113 may be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it may 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 methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor may be a microprocessor or any conventional processor.

[0040] The electronic device 100 in this embodiment can be used to execute various steps in the various methods provided in the embodiments of this application. The implementation process of the industrial design data version management method is described in detail below through several embodiments.

[0041] Please see Figure 2 This is a flowchart of the industrial design data version management method provided in the embodiments of this application. The following will describe... Figure 2 The specific process shown will be explained in detail.

[0042] Step 201: Map each design unit to a Git repository on the file system.

[0043] The design units here refer to reusable design units in industrial design. Examples include parts, subassemblies, and drawings.

[0044] Step 202: Store the internal attributes of the design unit as attribute files in the corresponding Git repository directory.

[0045] In this context, the filename of the attribute file represents the attribute name, and the file content of the attribute file represents the attribute value.

[0046] Optionally, this internal attribute can be a globally unique identifier, node type, material, diameter, surface treatment, etc. This internal attribute can be set according to actual needs.

[0047] The attribute file is a separate file.

[0048] The aforementioned attribute files can be either files without a file extension or text files with a formatted extension (such as .json files) to achieve a direct mapping between attributes and the file system.

[0049] In one embodiment, any program can access and modify industrial design data through standard file read and write operations, and the file system itself constitutes the API for data access.

[0050] Step 203: Express the assembly reference relationships between design units through Git's submodule mechanism.

[0051] The assembly hierarchy between design units is configured to be expressed through the nested relationship of directories in the file system.

[0052] For example, an assembly repository directory contains nested repository directories for its subordinate parts, thus eliminating the need for additional database adjacency tables or path enumerations to maintain the hierarchical structure, thereby improving query efficiency and data consistency.

[0053] It should be understood that, in the embodiments of this application, the assembly hierarchy between design units is naturally expressed through the nesting relationship of directories in the file system.

[0054] In one embodiment, an assembly repository references its subordinate part or sub-assembly repositories through a Git Submodule, thereby accurately recording reference snapshots between different version units and realizing versioning of assembly relationships.

[0055] Understandably, for the native formats of CATIA, NX, Creo, and SolidWorks, this embodiment stores them as binary data files of nodes (e.g., body.stp, shape.glb, etc.), while extractable attributes (name, material, etc.) are extracted as tiled attribute files. The upper layer is uniformly represented as "one directory + a set of attribute files + one native geometry file", which can shield the differences between multiple formats.

[0056] In the above implementation process, the "file as data" architecture stores attributes as files in the file system, eliminating the dual-source inconsistency problem caused by the separation of relational database metadata and file server entity files in traditional solutions. The file system and Git atomic commits jointly ensure data consistency. In addition, each reusable design unit is treated as an independent Git repository, enabling industrial design data to naturally acquire complete Git native capabilities such as version tracking, branch management, and merge conflict handling, without the need for additional version management logic development.

[0057] In one possible implementation, such as Figure 3 As shown, the design unit is configured to be split into entities and nodes.

[0058] Entities are configured as independent Git repositories to store common attributes; nodes are configured as submodules to store location-specific attributes.

[0059] Here, an entity can be referenced by multiple nodes through a submodule. Modifying an entity's repository property once will synchronously affect all referencing nodes by updating their pointers; the positional attributes of each node are independent.

[0060] Optionally, this general property may include material, geometry, etc., and can be selected according to the actual situation.

[0061] The entities described above define what a design unit "is." A "node" is defined as an instantiated reference to the entity, used to store specific location information (e.g., assembly coordinates or pose matrix) of the design unit within a particular assembly, thus defining where the design unit is "used." In this way, the same entity (e.g., a standard bolt) can be referenced by multiple nodes without copying any entity data, achieving a single data source and efficient data reuse.

[0062] In the above implementation process, through Git Submodules and entity / node separation, the same standard part can be referenced by multiple assembly locations. Modifying the entity once synchronizes all reference locations, while the positional attributes (transformation matrices, etc.) of each node remain independent, avoiding file copying or complex database reference maintenance in traditional solutions. Furthermore, the standardized file system interface and AI Agent interface give the system extremely high openness and scalability, allowing it to seamlessly integrate into future intelligent design processes.

[0063] In one possible implementation, such as Figure 4 As shown, the method also includes managing concurrent operations on a Git repository by multiple users through a server-side workspace.

[0064] Understandably, to support multi-user collaborative work, this application introduces a server-side workspace mechanism. Through the server-side workspace, concurrent operations and synchronization of multiple users on the Git repository are managed, thereby achieving efficient and secure collaborative design in a distributed environment.

[0065] In one embodiment, by borrowing Git's Fork + Pull Request pattern but fully server-side, it can be implemented through the following steps: The client calls the API to request the creation of a workspace; the server forks a temporary edit copy from the target repository; the client uploads / modifies files via HTTP, and the changes only affect the workspace; after editing, Commit → Push merges back to the source repository; if closed before Push, the changes are discarded; the client does not need to install Git or download the complete repository, making it suitable for lightweight environments such as web browsers and AI agents.

[0066] In the above implementation process, by setting up a server-side fork workspace mechanism, the client does not need to install Git or download the complete repository. It can complete the editing and submission of design data only through the HTTP API. It supports access from lightweight environments such as web browsers and AIAgent, increasing the application scenarios of this method.

[0067] In one possible implementation, concurrent operations on a Git repository by multiple users are managed through a server-side workspace, including: responding to client edit requests through a server-side workspace manager and creating isolated server-side workspaces from the source Git repository; responding to commit commands to submit changes locally to the server-side workspace; and responding to push commands to push and merge changes back to the source Git repository.

[0068] The server-side workspace is configured to allow clients to read and write attribute files via file operation interfaces.

[0069] In one embodiment, the client calls an API request to create a workspace (where the request parameters include the source repository ID, branch name, etc.), the server responds to the request, creates a fork copy of the source repository on the local disk using JGit (using Sparse Checkout and Partial Clone to optimize the performance of large repository cloning), assigns a unique workspace ID, records the workspace routing information (workspace ID → service instance address) in Redis, and changes the status to ACTIVE.

[0070] Clients perform file read and write operations in the workspace via the HTTP API. All changes only affect the forked copy, not the source repository. The system supports multiple clients editing the same workspace simultaneously, and data consistency is ensured through Git's concurrency conflict detection mechanism.

[0071] When the client calls the commit interface, the server performs add and commit operations on all changes in the ACTIVE state using JGit, generating a local commit object, and keeping the state ACTIVE (allowing further editing).

[0072] The client calls the push API, and the server executes a JGit push operation to push the local commit back to the origin repository. If there are no conflicts in the origin repository, the push is successful, and the status changes to CLOSE (closed); if there are conflicts, conflict information is returned to the client, and the status reverts to ACTIVE for the user to resolve the conflicts.

[0073] When a client calls the close interface or the session times out, the server cleans up the local disk files of the forked replicas, deletes the routing information in Redis, and releases resources. If the server closes directly in ACTIVE state, all uncommitted changes are discarded and not merged back into the source repository.

[0074] When deploying multiple server instances, Redis is used to store the mapping from workspace IDs to service instance addresses, ensuring that subsequent requests within the same workspace are routed to the correct service instance. In the event of a service instance failure, the system can rebuild the forked workspace from the raw Git repository, achieving fault recovery.

[0075] In the above implementation process, by setting up a server-side fork workspace mechanism, the client does not need to install Git or download the complete repository. It can complete the editing and submission of design data only through the HTTP API. It supports access from lightweight environments such as web browsers and AIAgent, increasing the application scenarios of this method.

[0076] In one possible implementation, the relational database is configured to store index data, the object storage is configured to store Git objects and large industrial files, and the local cache is configured to store hot data from the active workspace.

[0077] Large industrial files are stored in object storage using the Git LFS pointer mechanism, and the Git repository only retains pointer files that point to the actual content in object storage.

[0078] Optionally, the index data may include tenants, projects, warehouse affiliations, entity registration records, node registration records, attribute search inverted indexes, etc., and the index data can be selected according to the actual situation.

[0079] In one embodiment, the object storage stores Git objects and large industrial files through the JGit DfsRepository abstraction layer.

[0080] The Git LFS pointer mechanism stores the uploaded content in object storage, with only about 130 bytes of pointers remaining in the repository. When the client downloads the content, the pointers are automatically parsed and the actual content is obtained, making it completely transparent.

[0081] In the above implementation process, by setting up a three-tier storage architecture (i.e., relational database, object storage and large file, local cache) in conjunction with the Git LFS transparent pointer mechanism, it is possible to prevent Git repository from growing while maintaining the transparency of user operations, thus balancing storage efficiency and user experience.

[0082] In one possible implementation, such as Figure 5 As shown, the native format files of various drafting software are stored as binary data files in the corresponding directories, and the design attributes extracted from the native format files are laid out as attribute files in the directories.

[0083] Optionally, the binary data file can be .stp, .glb, etc., and the choice of binary data file can be made according to the actual situation. The binary file coexists with the attribute file.

[0084] The part attributes here are distributed across multiple files. For example, part_type_code, part_type_name, etc. tree / tree.json records the complete assembly tree structure, and semantics / stores the design semantic relationships.

[0085] In one embodiment, such as Figure 6 As shown, within the 2D scheme, the organization is based on drawings. The title block, views, and annotations of each drawing are stored in separate files or directories, following the attribute file tiling principle. Dimensions are expressed in separate files for easy version comparison.

[0086] For example, each attribute of an industrial design object is mapped to a separate file in the file system. For instance, a part called a "flange" is represented as follows: Parts - Flanges ├── UUID# contains "a1b2c3d4-..." (Globally unique ID) ├── node_type# Content is "PART" (node ​​type) ├── material# contains "45 steel" (material) ├── diameter# contains "10" (diameter) ├── surface_treatment # Content is "zinc plating" (surface treatment) ├── Geometric shape / │├── node_type# contains "GEOMETRY" │└── body.glb# Binary geometric data file └── Engineering drawing.dwg# Two-dimensional engineering Figure 2 Hexadecimal files In the above file structure, the name of each file without a file extension is the attribute name, and the file content is the attribute value. Binary data files (such as .glb, .dwg) are stored in their native format in the corresponding directory, coexisting with the attribute files. The hierarchical relationship is naturally expressed by directory nesting.

[0087] like Figure 7As shown, regarding support for multiple CAD formats, for CATIA's .CATPart files, NX's .prt files, Creo's .prt files, and SolidWorks' .sldprt files, the system stores them as binary data files in the node directory (e.g., body.stp, shape.glb). Simultaneously, design attributes extracted from these native format files (e.g., part name, material, mass, etc.) are laid out as attribute files in the same directory (e.g., part_type_code, material, etc.). Upper-level applications uniformly present this as "one directory + a set of attribute files + one or more native geometry files," without needing to be aware of the underlying CAD format.

[0088] In the above implementation process, by uniformly mapping the native formats of various mainstream CAD software to a directory structure of "attribute file + binary data file", the differences between different CAD formats can be shielded, and upper-level applications do not need to be aware of the underlying format.

[0089] In one possible implementation, the method also includes providing a standard toolset conforming to the Model Context Protocol (MCP) via an AI Agent interface.

[0090] The AI ​​Agent interface encapsulates Git's underlying operations with file operation semantics, and is configured to operate on design data in a way that reads and writes files.

[0091] In one embodiment, before providing a standard toolset conforming to the Model Context Protocol (MCP) through the AI ​​Agent interface, the method further includes encapsulating file system operations into a standard MCP toolset (e.g., list_directory, read_file, write_file, commit_changes, etc.).

[0092] The AI ​​Agent here reads and writes industrial design data using file manipulation semantics, and automatically handles Git commits and version tracking internally. It provides software development kits in multiple languages, including Python, Java, and TypeScript.

[0093] In the above implementation process, by encapsulating the underlying Git operations into file operation semantics, the AI ​​Agent can operate on industrial design data in a way that reads and writes files, which greatly reduces the integration threshold between AI and industrial design systems.

[0094] In one possible implementation, such as Figure 6As shown, the method also includes: performing configuration inheritance and incremental overriding step by step according to the global default configuration layer, tenant enterprise configuration layer, team configuration layer and project configuration layer; and declaring the configuration merging chain through the manifest.json file in each level directory.

[0095] Each level of configuration change is stored with an independent Git commit record.

[0096] Understandably, the system in this application embodiment adopts a four-level configuration inheritance and overriding mechanism: global default configuration layer → tenant enterprise configuration layer → team configuration layer → project configuration layer. Specifically, the global default configuration layer, located in the global / config / directory, defines platform-level default configurations, such as default diagram templates and default annotation specifications; the tenant enterprise configuration layer, located in the tenants / {tenant_id} / enterprise / config / directory, defines enterprise-level configuration increments, overriding corresponding items in the global layer; the team configuration layer, located in the tenants / {tenant_id} / teams / {team_id} / config / directory, defines team-level configuration increments, overriding corresponding items in the enterprise layer; and the project configuration layer, located in the tenants / {tenant_id} / teams / {team_id} / projects / {project_id} / config / directory, defines project-level configuration increments, overriding corresponding items in the team layer.

[0097] When the system starts up or a configuration change occurs, it calculates the merged effective configuration level by level, starting from the global default configuration layer. Each configuration change is recorded via Git commit, ensuring complete traceability of the configuration history. The final instance (3D project or 2D solution) can define increments in its own configuration, recording only the differences from the upper-level configuration to minimize configuration redundancy.

[0098] Platform-level standard data is stored in the global / standards / directory, which is an independent Git repository and does not belong to any tenant. Specifically, it includes: national standard geometric tolerance tables, thread data from various CAD software, and original Excel data sources for record-keeping, etc.

[0099] Among them, such as Figure 7 As shown, tenants can reference standard data in two modes: live mode: declare the path link in the tenant configuration, and the system automatically tracks the latest commits of global / standards / when reading, which is suitable for scenarios that need to keep up with standard updates in real time; frozen mode: record the commit SHA of a specific version snapshot in the tenant's refs / manifest.json, and lock the version when the system reads, which is suitable for scenarios that need to be authenticated through a specific standard version.

[0100] In the above implementation process, the cross-tenant read-only standard data layer, combined with live / frozen dual-mode references, can ensure the consistency of standard data versions while allowing tenants to choose tracing strategies as needed.

[0101] In one possible implementation, the method further includes: establishing a first target directory on top of tenant-isolated business data.

[0102] The first target directory is configured to store national standard geometric tolerance tables and thread data from multiple CAD software programs; the business data of different tenants are physically isolated in the second target directory, and each tenant has an independent namespace and access control; tenants reference standard data through various modes.

[0103] Each logical unit (tenant, team, project, engineering, solution, standard) in this directory is an independent Git repository. The naming can follow the {entityType}-{entityId}.git specification, and its position in the hierarchy is recorded through manifest.json.

[0104] For example, Git repository mapping rules can be shown in the table below.

[0105]

[0106] The aforementioned repositories are stored as bare repositories in object storage (via DfsRepository). When they are checked out to the server-side workspace, they are reorganized according to the directory tree structure described above. Submodule cascading ensures the version independence of each component and the consistency of the overall assembly tree.

[0107] In one embodiment, such as Figure 8 As shown, an independent Git repository is defined by its hierarchical structure in manifest.json. Physically, each repository is stored independently, and during checkout, they are reorganized according to the directory tree. References between levels are implemented using Git submodules: for example, the Project repository mounts Engineering as a submodule under 3d / {engineering_id} / , and Engineering further mounts its various Parts as submodules under files / {group_id} / .

[0108] To illustrate more specifically how the "file as data architecture" is implemented in this application's embodiments, a complete file system view from global standards to specific engineering diagrams under a tenant is given below.

[0109] Complete directory tree example: global / # Platform-level Cross-tenancy └── standards / ├── gb / geometric_tolerance.json# National Standard Geometric Tolerance Table ├── cad_thread / {solidworks,catia,nx,creo}.json # Thread data for various CAD software └── cad_thread / {solidworks,catia,nx,creo}.xlsx # Original Excel data source tenants / {tenant_id} / ├── enterprise / # Enterprise Space · Global Configuration Root │├── meta.json │├── config / # Enterprise configuration ││├── drawing_config.json# Drawing / Frame Configuration ││└── Parts Library / ││├── dimension_setting.json# Annotation configuration ││└── ... │├── profiles / # Business projection configuration │└── templates / # Templates │ ├── teams / {team_id} / # Team Space │├── meta.json │├── config / # Team-level configuration │├── profiles / │├── templates / ││ │└── projects / {project_id} / # Basic unit of project version control │├── meta.json │├── config / # Project-level configuration ││└── manifest.json# Configure merge chain declaration ││ │├── 3d / {engineering_id} / # 3D Digital Modeling Engineering ││├── meta.json ││├── config / # Incremental configuration at the project level │││├── manifest.json │││└── ... ││├── semantics / # Semantic layer │││├── meta.json │││├── index.json │││└── relations / {type} / {tag}.json ││├── files / {group_id} / # Part files │││├── part_type_code# Property file │││├── part_type_name# Attribute file │││├── geometries# associated geometry group_id │││├── part_feature.json# Manually annotated features │││├── body.stp# Boundary Representation (STEP) │││├── shape.glb# Front-end visualization (GLB) │││├── brep.json# BRep data │││├── geometry_feature.json# Topological features │││└── agent_feature.json# AI Agent Recognition Results ││├── tree / # Assembly tree definition │││└── tree.json ││├── assembly / # Assembly-related constraints ││└── scenes / {sub_scene_id} / # Sub-scenes ││ │├── 2d / {solution_id} / # 2D Solution Design Results ││├── meta.json ││├── config / │││├── manifest.json# 2D projection merging chain │││├── templates / {id} / │││└── ... ││├── frames / # drawing frames ││├── drawings / # Drawing collection │││└── {drawing_id} / # Single drawing sheet │││├── dynamic_data │││├── views_ref │││├── table │││└── frame_instance ││├── views / {viewUuid} / # Views │││├── projection / # Projection primitives │││├── dimensions / # Dimensioning │││└── bindings / {tag}.json # Tag and Semantic Binding ││├── delivery / dwg / # Export DWG data ││├── links / graph.json ││└── _source / # Read-only reference data ││ │└── standards / {standard_id} / # Project Standards │├── meta.json │└── library / # Standard Parts Library │├── library_branch │├── library_config │├── design_type │├── drawing.json │└── drawing_name In the above implementation process, the cross-tenant read-only standard data layer, combined with live / frozen dual-mode references, can ensure the consistency of standard data versions while allowing tenants to choose tracing strategies as needed.

[0110] Based on the same application concept, this application also provides an industrial design data version management system corresponding to the industrial design data version management method. Since the principle of the device in this application is similar to that of the aforementioned industrial design data version management method, the implementation of the system in this application can refer to the description in the above method embodiments, and the repeated parts will not be repeated.

[0111] Please see Figure 9 This is a schematic diagram of the functional modules of the industrial design data version control system provided in this application embodiment. Each module in the industrial design data version control system of this embodiment is used to execute the steps in the above method embodiments. The industrial design data version control system includes a Git repository mapping layer, a file system abstraction layer, and a relational representation layer; wherein, The Git repository mapping layer is used to map each design unit to a Git repository on the file system.

[0112] The file system abstraction layer is used to store the internal attributes of the design unit as attribute files in the corresponding Git repository directory; wherein, the file name of the attribute file represents the attribute name, and the file content of the attribute file represents the attribute value.

[0113] The relationship expression layer is used to express the assembly reference relationship between the design units through Git's submodule mechanism; wherein, the assembly hierarchy relationship between the design units is configured to be expressed through the nesting relationship of directories in the file system.

[0114] In one possible implementation, a management layer is also included for managing concurrent operations on the Git repository by multiple users through a server-side workspace.

[0115] In one possible implementation, the management layer is specifically configured to: respond to client edit requests via the server-side workspace manager and create isolated server-side workspaces from the source Git repository; wherein the server-side workspaces are configured to allow clients to read and write attribute files via file operation interfaces; respond to commit commands to submit changes locally to the server-side workspaces; and respond to push commands to push and merge the changes back to the source Git repository.

[0116] In one possible implementation, a storage layer is further included, which is used to respond to the client's edit request through the server-side workspace manager and create an isolated server-side workspace from the source Git repository; wherein the server-side workspace is configured to allow the client to read and write attribute files through a file operation interface; to submit changes to the local server-side workspace in response to a commit command; and to push the changes back to the source Git repository in response to a push command.

[0117] One possible implementation also includes a standard tools layer for providing a standard toolset conforming to the Model Context Protocol (MCP) via an AI Agent interface; wherein the AI ​​Agent interface encapsulates Git underlying operations with file operation semantics, and the AI ​​Agent interface is configured to operate on design data in a read-write file manner.

[0118] One possible implementation also includes a configuration layer for hierarchical configuration inheritance and incremental overriding according to the global default configuration layer, tenant enterprise configuration layer, team configuration layer and project configuration layer; wherein configuration changes at each level are stored with independent Git commit records; and configuration merge chains are declared through manifest.json files in each level directory.

[0119] One possible implementation also includes a directory creation layer for establishing a first target directory on top of tenant-isolated business data; wherein the first target directory is configured to store national standard geometric tolerance tables and thread data from multiple CAD software programs; the business data of different tenants are physically isolated in a second target directory, and each tenant has an independent namespace and access control; the tenants reference standard data through multiple modes.

[0120] Furthermore, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the steps of the industrial design data version management method described in the above method embodiments.

[0121] The computer program product of the industrial design data version management method provided in this application includes a computer-readable storage medium storing program code. The instructions included in the program code can be used to execute the steps of the industrial design data version management method described in the above method embodiments. For details, please refer to the above method embodiments, which will not be repeated here.

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

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

[0124] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks. It should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element. The above description is merely a preferred embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application. It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0125] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for managing industrial design data versions, characterized in that, include: Map each design unit to a Git repository on the file system; The internal attributes of the design unit are stored as attribute files in the corresponding Git repository directory; wherein, the file name of the attribute file represents the attribute name, and the file content of the attribute file represents the attribute value; The assembly reference relationships between the design units are expressed through Git's submodule mechanism; wherein, the assembly hierarchy relationships between the design units are configured to be expressed through the nesting relationships of directories in the file system.

2. The method according to claim 1, characterized in that, The design unit is configured to be split into entities and nodes; The entity is configured as an independent Git repository to store common attributes; the node is configured as a submodule to store location-specific attributes.

3. The method according to claim 1, characterized in that, The method further includes: The server-side workspace manager responds to client editing requests and creates isolated server-side workspaces from the source Git repository; wherein, the server-side workspace is configured to allow clients to read and write property files through file operation interfaces; The response to the commit command will submit the changes to the local server workspace; and The changes are pushed back to the source Git repository in response to the push command.

4. The method according to claim 1, characterized in that, in, The relational database is configured to store index data, the object storage is configured to store Git objects and large industrial files, and the local cache is configured to store hot data in the active workspace. The large industrial files are stored in the object storage using the Git LFS pointer mechanism, and the Git repository only retains pointer files that point to the actual content in the object storage.

5. The method according to claim 1, characterized in that, The native format files of various drafting software are stored as binary data files in the corresponding directories, and the design attributes extracted from the native format files are laid out as attribute files in the directory.

6. The method according to claim 1, characterized in that, Also includes: Provides a standard toolset conforming to the Model Context Protocol (MCP) through the AI ​​Agent interface; The AI ​​Agent interface encapsulates Git's underlying operations with file operation semantics, and is configured to operate on design data in a file-reading and file-writing manner.

7. The method according to claim 1, characterized in that, Also includes: Configuration inheritance and incremental overriding are performed in a hierarchical manner, following the global default configuration layer, tenant enterprise configuration layer, team configuration layer, and project configuration layer; configuration changes at each level are stored with independent Git commit records. as well as The merge chain is configured by declaring the manifest.json file in each directory level.

8. An industrial design data version management system, characterized in that, include: The Git repository mapping layer is used to map each design unit to a Git repository on the file system; The file system abstraction layer stores the internal attributes of the design unit as attribute files in the corresponding Git repository directory; wherein, the file name of the attribute file represents the attribute name, and the file content of the attribute file represents the attribute value; The relationship expression layer expresses the assembly reference relationships between the design units through Git's submodule mechanism; wherein, the assembly hierarchy relationship between the design units is configured to be expressed through the nested relationship of directories in the file system.

9. An electronic device, characterized in that, include: The processor and memory, wherein the memory stores machine-readable instructions executable by the processor, wherein when the electronic device is running, the machine-readable instructions are executed by the processor to perform the steps of the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, performs the steps of the method as described in any one of claims 1 to 7.

Images