Geometric tokens in foundation model for mechanical design
The computing system addresses the interdependence issue in mechanical design by encoding geometric tokens for unified task execution, enhancing design coherence and efficiency.
Patent Information
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- SIEMENS INDUSTRY SOFTWARE INC
- Filing Date
- 2025-09-30
- Publication Date
- 2026-06-11
Smart Images

Figure US2025048647_11062026_PF_FP_ABST
Abstract
Description
202421203 GEOMETRIC TOKENS IN FOUNDATION MODEL FOR MECHANICAL DESIGNRELATED APPLICATION
[0001] This application claims priority and benefit of U. S. Provisional Patent Application No. 63 / 728,253, filed, December 5, 2024, which is incorporated by reference herein in its entirety.TECHNICAL FIELD
[0002] This application is generally related to mechanical design automation and, more specifically, to utilizing geometric tokens in a foundation model to perform multiple interdependent tasks in mechanical design development.BACKGROUND
[0003] Mechanical design of products typical involves performing multiple interdependent tasks, such as sketching, three dimensional (3D) modeling, drafting, assembly, reverse engineering, design refactoring, simulation, or the like. These mechanical design tasks usually rely on a variety of data inputs, in differing representations and / or modalities. For example, the mechanical design task of sketching typically involves operating on two dimensional (2D) profiles associated with a product, 3D modeling tasks operate with 3D geometries associated with the product, assembly design tasks work with multiple different geometries, or the like. Performance of any individual mechanical design task can be understand how to manipulate those input to create an output of the product. For example,202421203 when a mechanical design task reverse-engineers a 3D geometry from multiple 2D design input, a designer may analyze the 2D design inputs, such as a technical drawing, an associated image of the product, or the like, and accurately create the 3D geometry of the product from those inputs. Some designers utilize computing systems, for example, including some machine learning (ML) and / or artificial intelligence (AI) algorithms, to help perform at least a portion of individual mechanical design tasks, for example, feature prediction using sequential models, assembly mate prediction, or the like. While the utilization of computing systems with AI / ML algorithms has aided designers in performing those individual tasks, the siloed approach to task performance ignores the interdependence of these mechanical design tasks, can lead to task outputs for the product that conflict, are incongruent, or correspond to sub-optimal product designs.SUMMARY
[0004] This application discloses a computing system to analyze a geometric representation of the mechanical part to identify a topological connectivity for faces and edges of the mechanical part, sample the faces and the edges of the mechanical part described in the geometric representation of the mechanical part, separately encode the samples of the faces and the edges of the mechanical part into geometric tokens, and combine the geometric tokens according to the topological connectivity for the faces and the edges in the mechanical part. The computing system can implement a machine-learning algorithm that can utilize the combined geometric tokens to generate output tokens that, when decoded, correspond to one or more tasks configured for implementation by a mechanical design tool202421203 developing a mechanical design including the mechanical part. Embodiments will be described in greater detail below.DESCRIPTION OF THE DRAWINGS
[0005] Figures 1 and 2 illustrate an example of a computer system of the type that may be used to implement various embodiments.
[0006] Figure 3 illustrates an example of a mechanical design system having a foundation model for mechanical design prediction using geometric tokens according to various embodiments.
[0007] Figure 4 illustrates an example of a geometric encoding system of a mechanical design system according to various embodiments.
[0008] Figure 5 illustrates an example flowchart for generating geometric tokens for consumption by a foundation model according to various embodiments.
[0009] Figure 6 illustrates an example of a multi-domain decoding system of a mechanical design system according to various embodiments.
[0010] Figure 7 illustrates an example flowchart for xxx according to various embodiments.DETAILED DESCRIPTIONIllustrative Operating Environment202421203
[0011] Various embodiments may be implemented through the execution of software instructions by a computing device 101, such as a programmable computer. Accordingly, Figure 1 shows an illustrative example of a computing device 101. As seen in this figure, the computing device 101 includes a computing unit 103 with a processing unit 105 and a system memory 107. The processing unit 105 may be any type of programmable electronic device for executing software instructions, but will conventionally be a microprocessor. The system memory 107 may include both a read-only memory (ROM) 109 and a random access memory (RAM) 111. As will be appreciated by those of ordinary skill in the art, both the read-only memory (ROM) 109 and the random access memory (RAM) 111 may store software instructions for execution by the processing unit 105.
[0012] The processing unit 105 and the system memory 107 are connected, either directly or indirectly, through a bus 113 or alternate communication structure, to one or more peripheral devices 117-123. For example, the processing unit 105 or the system memory 107 may be directly or indirectly connected to one or more additional memory storage devices, such as a hard disk drive 117, which can be magnetic and / or removable, a removable optical disk drive 119, and / or a flash memory card. The processing unit 105 and the system memory 107 also may be directly or indirectly connected to one or more input devices 121 and one or more output devices 123. The input devices 121 may include, for example, a keyboard, a pointing device (such as a mouse, touchpad, stylus, trackball, or joystick), a scanner, a camera, and a microphone. The output devices 123 may include, for example, a monitor display, a printer and speakers. With various examples of the computing device 101, one or more of the peripheral devices 117-123 may be internally housed with the202421203 computing unit 103. Alternately, one or more of the peripheral devices 117-123 may be external to the housing for the computing unit 103 and connected to the bus 113 through, for example, a Universal Serial Bus (USB) connection.
[0013] With some implementations, the computing unit 103 may be directly or indirectly connected to a network interface 115 for communicating with other devices making up a network. The network interface 115 can translate data and control signals from the computing unit 103 into network messages according to one or more communication protocols, such as the transmission control protocol (TCP) and the Internet protocol (IP). Also, the network interface 115 may employ any suitable connection agent (or combination of agents) for connecting to a network, including, for example, a wireless transceiver, a modem, or an Ethernet connection. Such network interfaces and protocols are well known in the art, and thus will not be discussed here in more detail.
[0014] It should be appreciated that the computing device 101 is illustrated as an example only, and it is not intended to be limiting. Various embodiments may be implemented using one or more computing devices that include the components of the computing device 101 illustrated in Figure 1, which include only a subset of the components illustrated in Figure 1, or which include an alternate combination of components, including components that are not shown in Figure 1. For example, various embodiments may be implemented using a multi-processor computer, a plurality of single and / or multiprocessor computers arranged into a network, or some combination of both.202421203
[0015] With some implementations, the processor unit 105 can have more than one processor core. Accordingly, Figure 2 illustrates an example of a multi-core processor unit 105 that may be employed with various embodiments. As seen in this figure, the processor unit 105 includes a plurality of processor cores 201A and 201B. Each processor core 201A and 201B includes a computing engine 203A and 203B, respectively, and a memory cache 205A and 205B, respectively. As known to those of ordinary skill in the art, a computing engine 203A and 203B can include logic devices for performing various computing functions, such as fetching software instructions and then performing the actions specified in the fetched instructions. These actions may include, for example, adding, subtracting, multiplying, and comparing numbers, performing logical operations such as AND, OR, NOR and XOR, and retrieving data. Each computing engine 203A and 203B may then use its corresponding memory cache 205A and 205B, respectively, to quickly store and retrieve data and / or instructions for execution.
[0016] Each processor core 201A and 201B is connected to an interconnect 207. The particular construction of the interconnect 207 may vary depending upon the architecture of the processor unit 105. With some processor cores 201A and 20 IB, such as the Cell microprocessor created by Sony Corporation, Toshiba Corporation and IBM Corporation, the interconnect 207 may be implemented as an interconnect bus. With other processor units 201A and 20 IB, however, such as the Opteron™ and Athlon™ dual-core processors available from Advanced Micro Devices of Sunnyvale, California, the interconnect 207 may be implemented as a system request interface device. In any case, the processor cores 201A and 201B communicate through the interconnect 207 with an input / output interface 209202421203 and a memory controller 210. The input / output interface 209 provides a communication interface to the bus 113. Similarly, the memory controller 210 controls the exchange of information to the system memory 107. With some implementations, the processor unit 105 may include additional components, such as a high-level cache memory accessible shared by the processor cores 201A and 20 IB. It also should be appreciated that the description of the computer network illustrated in Figure 1 and Figure 2 is provided as an example only, and it is not intended to suggest any limitation as to the scope of use or functionality of alternate embodiments.Geometric Tokens in Foundation Model for Mechanical Design
[0017] Figure 3 illustrates an example of a mechanical design system 300 having a foundation model for mechanical design prediction using geometric tokens according to various embodiments. Referring to Figure 3, the mechanical design system 300 can include a geometric encoding system 310 to identify geometric input data 301 describing features of a mechanical design for a product. The geometric input data 301 can include 3D geometric representations of a part or mechanical device, for example, boundary representations of a 3D shape (B-Reps), point clouds, voxels, or the like. The geometric input data 301 also can include computer-aided design (CAD) features, such as feature trees, to provide a structured representation of steps taken to create a part or mechanical device. The geometric input data 301 can include manufacturing information, such as material indicators, product manufacturing information, or the like, and simulation information, such as 3D fields, or the like.202421203
[0018] The geometric encoding system 310 can encode the geometric input data 301 into geometric tokens 311 configured for consumption by a foundation model system 320 that includes a machine-learning algorithm. The geometric encoding system 310 can include a plurality of modality-specific encoders, which can each process the geometric input data 301 having a particular modality or representation to create modality-specific encodings for the geometric tokens 311 and project the geometric tokens 311 into a data space corresponding to the machine-learning algorithm of the foundation model system 320. The modalities of the geometric input data 301, which may be used interchangeably with representations of the geometric input data 301, can correspond to perceivable input, such as sounds, images, or the like. Embodiments of the geometric encoding system 310 will be described below in greater detail with reference to Figures 4 and 5.
[0019] Figure 4 illustrates an example of a geometric encoding system 400 of a mechanical design system according to various embodiments. Figure 5 illustrates an example flowchart for generating geometric tokens for consumption by a foundation model according to various embodiments. Referring to Figures 4 and 5, the geometric encoding system 400 can receive geometric input data 401 describing features of a mechanical design for a product, for example, as 3D geometric representations of a mechanical part or mechanical device, CAD features, feature trees, manufacturing information, simulation information, or the like.
[0020] The geometric encoding system 400, in a block 501 of Figure 5, can identify a topological connectivity for faces and edges of a geometric representation of a mechanical part described in geometric input data 401. In some embodiments, the geometric encoding202421203 system 400 can build a topological graph of the mechanical part to describe the connectivity and physical interrelations between the faces and the edges of the mechanical part described in the geometric input data 401. For example, the topological graph can include nodes corresponding to the faces of the mechanical part and include edges that connect between the nodes, which correspond to the edges of the mechanical part.
[0021] The geometric encoding system 400 can include a geometry encoder 410 to process portions of the geometric input data 401 corresponding to 3D geometry of the mechanical design to generate corresponding tokens. The geometry encoder 410 can include a plurality of modality-specific encoders 411-1 to 411-M, each to process geometric input data 401 having a particular modality to create modality-specific encodings for the tokens. For example, the modality- specific encoders 411-1 to 411-M can include encoders that process boundary representation data, part material data, point clouds associated with the mechanical design, voxel data, 3D fields, model-based definition (MBD) notes, product manufacturing information, drawings, CAM program data, feature graphs, design context data, or the like. In some embodiments, the modality-specific encoders 411-1 to 411-M can include transformation functions that operate on the particular modalities of the geometric input data 401 to create encodings for tokens.
[0022] The geometric encoding system 400, in a block 502 of Figure 5, can sample the faces and the edges of the mechanical part described in the geometric representation of the mechanical part. In some embodiments, the geometric encoding system 400 can use a UV sample grid, a faceted tessellation, or the like, to sample the faces and the edges of the mechanical part described in the geometric representation. The UV sample grid can have a202421203 set of points, arranged in a row-column format, distributed across the faces and / or edges of the mechanical part. The faceted tessellation can have a set of facets or connected shapes that substantially cover the faces and / or edges of the mechanical part. The density of the sets of points in the UV sample grid and size and / or density of the facets in the faceted tessellation can vary based on the types of the modality-specific encoders 411-1 to 411-M available in the geometry encoder 410, the processing capability of the geometric encoding system 400 and / or the foundation model system consuming the geometric tokens 311, or the like. The geometric encoding system 400 can sample the points in the UV sample grid or facets in the faceted tessellation, which together can correspond to the sampling of the faces and the edges of the mechanical part described in the geometric representation of the mechanical part.
[0023] The geometry encoder 410, in a block 503 of Figure 5, can separately encode the samples of the faces and the edges of the mechanical part into geometric tokens 402. In some embodiments, the geometry encoder 410 can select one or more of the modalityspecific encoders 411-1 to 411-M that corresponds to the modality associated with the samples of the face and / or the edges, and then utilize the selected modality-specific encoders 411-1 to 411-M to generate the geometric tokens 402 from the samples of the faces and / or the edges of the mechanical part.
[0024] In some embodiments, when the geometric input data 401 corresponds to a feature tree of the computer aided design (CAD) model, the geometry encoder 410 can translate the feature tree into a domain specific representation for use in conjunction with a 3D geometric representation of the mechanical part. One or more of the modality-specific202421203 encoders 411-1 to 411-M can utilize the domain specific representation to encode the feature tree into one or more geometric tokens 402, for example, with a with a pre-defined context window size. In some embodiments, the context window for the feature tree can correspond to a number of features in focus by a foundation model and, which may be a user-specified parameter.
[0025] The geometric encoding system 400 can include a space projection system 420 to project the geometric tokens 402 into a data space corresponding to the machine-learning algorithm of the foundation model system. In some embodiments, the geometric tokens from the geometry encoder 410 can have different data sizes and / or correspond to different data spaces, the space projection system 420 can transform the tokens into a common data space to generate the geometric tokens 402.
[0026] The space projection system 420, in a block 504 of Figure 5, can combine the geometric tokens 402 according to the topological connectivity for the faces and the edges in the mechanical part. In some embodiments, the space projection system can arrange the geometric tokens 402 relative to each other based on the topological graph generated by the geometric encoding system 400, for example, arranging geometric tokens corresponding to faces to geometric tokens corresponding to edges based on the nodes and edges in the topological graph. The combined geometric tokens 402 can correspond to a graph-level tokenized representation of the geometric input data 401 capable of consumption by a foundation model system 320 in the mechanical design system 300.202421203
[0027] Referring to Figures 3 and 5, the foundation model system 320 can include a machine-learning algorithm that, in a block 505 of Figure 5, can analyze the combined geometric tokens to generate output tokens that, when decoded, correspond to one or more tasks configured for implementation by a mechanical design tool. The combined geometric tokens can be modality- specific representations of the geometric input data 301 that have been arranged based on a topological connectivity of the mechanical part described in the geometric input data 301 and projected into a common data space for consumption by the machine-learning algorithm in the foundation model system 320. The output tokens 321 can correspond to a series of tokens in a unified representation, abstracted over the tasks involved in mechanical design.
[0028] The foundation model system 320 can generate the output tokens 321 in a foundation language (FxL) for computer aided technologies (CAx), having a structured syntax and semantics to define instructions and tasks for implementation across multiple computer aided design tools. In some embodiments, the output tokens 321 can specify the tasks in a declarative foundation language, which can be agnostic of a type of mechanical design tool to implement the tasks and can be configured to capture one or more of design intent, functional features, assemblies, drafting, manufacturing, simulation, and modelbased design to geometric elements associated with the tasks. Embodiments of the foundation language (FxL) will be described below in greater detail.
[0029] The mechanical design system 300 can include a multi-domain decoding system 330 to decode domain- specific operations embedded in the output tokens 321 to determine one or more tasks 332 with corresponding instructions configured for implementation by the202421203 mechanical CAD system 340. In some embodiments, the output tokens 321 can include multiple series of tokens that each can correspond to a different instruction, defined based on the semantics and syntax of the series of the tokens. For example, a first token in a series of tokens can correspond to a domain identification token, which can annunciate a domain associated with the instruction in that series of tokens. The remaining tokens in the series, when decoded for the domain in the domain identification token, can have a syntax and semantics to allow the multi-domain decoding system 330 to generate the instruction for the particular domain. The multi-domain decoding system 330 can utilize the structure of the output tokens 321 to group the decoded instructions into the tasks 332 and then output the tasks 332 to the mechanical CAD system 340 for processing.
[0030] The mechanical CAD system 340 can utilize the tasks 332 having the corresponding instructions to predict a domain- specific feature for the mechanical design. In some embodiments, the mechanical CAD system 340 can utilize the tasks 332 for predictions of part, assembly, manufacture characteristics that can be implemented in the development of the mechanical design for a product.
[0031] Figure 6 illustrates an example of a multi-domain decoding system 600 of a mechanical design system according to various embodiments. Referring to Figure 6, the multi-domain decoding system 600 can receive output tokens 601 embedded with domainspecific operations generated by a machine-learning algorithm. In some embodiments, the output tokens 601 can include multiple series of tokens that each can correspond to different instructions, defined based on the semantics and syntax of the series of the tokens. Each of the different series of tokens can include a domain identification token, which can202421203 annunciate a domain associated with the instruction in the respective series of tokens. The remaining tokens in each series can correspond to a tokenized representation of those instructions.
[0032] The multi-domain decoding system 600 can include a geometry decoder 610 to parse the output tokens 601 to locate tokens identifying different types of decoders to process the corresponding domain- specific operations. In some embodiments, after the geometry decoder 610 locates the domain identification token within the output tokens 601 and select the type of decoding to utilize to decode a portion of the output tokens 601 based on the domain identification token.
[0033] The geometry decoder 610 can separately decode the domain- specific operations from the output tokens 601 using the decoding specified in the domain- specific operations, which generates instructions. In some embodiments, the geometry decoder 610 can include a plurality of domain- specific decoders 611-1 to 611-N, each to implementing a different type of decoding, which can transform the embedding from the output tokens 601 into instructions. For example, the domain-specific decoders 611-1 to 611-N can process different portions of the output tokens 601 to generate instructions corresponding to boundary representation data, part material data, point clouds associated with the mechanical design, voxel data, 3D fields, model-based definition (MBD) notes, product manufacturing information, drawings, CAM program data, feature graphs, design context data, or the like.202421203
[0034] In some embodiments, the geometry decoder 610 can process the output tokens 601 specified in the foundation language (FxL) to identify a domain associated with the embedded instruction and to decode the embedded instruction for inclusion in the one or more tasks 603. Below are examples of different tasks 603 with instructions specified in the foundation language FxL.
[0035] An example code snippet of a feature task in a foundation language FxL format:"'featureNEW_SELECTION sketchFeature FEATURE name:=" Sketch3" NEW_SELECTION upToFace ENTITY FACE (AT [0.00.00.00985]) NEW_FEATURE EXTRUDE name: -'Extrude 1" profile:=sketchFeaturetype: =UP_TO_SURFACE entity: =upToF ace
[0036] The example code snippet can be represented by a series of tokens. For example, the symbol can be represented by a token, which can correspond to a beginning, or an ending of a token series associated with the feature task. The task identifier token following the symbol at the beginning of the token series can indicate a type of task embedded in the token series, which in this instance corresponds to a feature creation task. The tokens following the task identifier tokens can describe the feature creation task to be performed by a mechanical computer-aided design tool, which in this instance corresponds to the creation of an extrusion feature.
[0037] An example code snippet of a sketch task in a foundation language FxL format:202421203
[0038] sketchNEW_SELECTION sketchFace ENTITY FACE (AT [0.00.00.01515]) NEW_FEATURE SKETCH " Sketch4" sketchFaceNEW_ENTITY CIRCLE center: =(@TEMP NEW_ENTITY POINT [00.00.01515]) rachus:=0.005875NEW_ENTITY POINT [00.00.01515]
[0039] The example code snippet can be represented by a series of tokens. For example, the symbol can be represented by a token, which can correspond to a beginning, or an ending of a token series associated with the sketch task. The task identifier token following the symbol at the beginning of the token series can indicate a type of task embedded in the token series, which in this instance corresponds to a sketch creation task. The tokens following the task identifier tokens can describe the sketch creation task to be performed by a mechanical computer-aided design tool, which in this instance corresponds to the creation of a circle sketch centered at a particular point and having a particular radius.
[0040] An example code snippet of a material task in a foundation language FxL format:
[0041] " "materialNEW_SELECTION body ENTITY BODY (AT [0.00.00.0]) ASSIGN_MATERIAL body " Aluminum_5086"
[0042] The example code snippet can be represented by a series of tokens. For example, the symbol can be represented by a token, which can correspond to a beginning, or an ending of a token series associated with the material task. The task identifier token following the symbol at the beginning of the token series can indicate a type of task embedded in the token series, which in this instance corresponds to a material assignment task. The tokens following the task identifier tokens can describe the material assignment202421203 task to be performed by a mechanical computer-aided design tool, which in this instance corresponds to assigning an aluminum material to a body section of a mechanical design.
[0043] An example code snippet of an assembly task in a foundation language FxL format:"'assemblyNEW_SELECTIONbodyl ENTITY BODY (AT [0.00.00.0]) CREATE_CONSTRAINT entity: =[bodyl] dof:=nullNEW_SELECTION facet ENTITY FACE (AT [0.00.00.01515]) NEW_SELECTION face2 ENTITY FACE (AT [0.00.00.00985]) CREATE_CONSTRAINT entity:=[facel, face2] dof:=[dz, rz]
[0044] The example code snippet can be represented by a series of tokens. For example, the symbol can be represented by a token, which can correspond to a beginning, or an ending of a token series associated with the assembly task. The task identifier token following the symbol at the beginning of the token series can indicate a type of task embedded in the token series, which in this instance corresponds to an assembly task. The tokens following the task identifier tokens can describe the assembly task to be performed by a mechanical computer-aided design tool, which in this instance corresponds to constraining a body to have no degrees of freedom (dof:=null) and constraining faces (facet and face 2) so they can move along the vertical z-axis and rotate along the z-axis (dof:=dz,rz).
[0045] An example code snippet of a neutral-to-boundary representation (n2b) task in a foundation language FxL format:
[0046] "n2bCREATE_CURVE curve1 type:=LINE point:=[7.0, -10.0, 7.0] dn:=[-1.0, 0.0, 0.0]202421203 CREATE_EDGE edgel curve:=curvel pl:=0.0 p2:=10.0CREATE_WIRE wire2 edges:=[edge5, edge6, edge7, edge8] CREATE_SURFACE surfacel type:=PLANE point:=[0.0, -10.0, 0.0] dn:=[0.0, -1.0, 0.0]CREATE_FACE facel surface:=surfacel wires:=[wirel, wire2]CREATE_SOLID solid1 faces:=[face1, face2, face3, face4, face5]
[0047] The example code snippet can be represented by a series of tokens. For example, the symbol can be represented by a token, which can correspond to a beginning, or an ending of a token series associated with the neutral-to-boundary representation (n2b) task. The task identifier token following the symbol at the beginning of the token series can indicate a type of task embedded in the token series, which in this instance corresponds to the neutral-to-boundary representation (n2b) task. The tokens following the task identifier tokens can describe the assembly task to be performed by a mechanical computer-aided design tool, which in this instance corresponds to creating a curved line, bounding the curved line to create an edge, creating a wire corresponding to a set of edges that form a loop, defining a surface, creating a face from one or more wires and the surface, and finally creating a solid object from a plurality of created faces.
[0048] An example code snippet of a simulation task in a foundation language FxL format:"'simulationNEW_SELECTION face ENTITY FACE (AT [0.0, 5.0, 1.515]) NEW_SELECTION nodes ENTITY NODE from:=[face] APPLY_BOUNDARY_CONDITION type:=DISPLACEMENT directions value:=0 SOLVE
[0049] The example code snippet can be represented by a series of tokens. For example, the symbol can be represented by a token, which can correspond to a beginning, or an202421203 ending of a token series associated with the simulation task. The task identifier token following the symbol at the beginning of the token series can indicate a type of task embedded in the token series, which in this instance corresponds to the simulation task. The tokens following the task identifier tokens can describe the assembly task to be performed by a mechanical computer-aided design tool, which in this instance corresponds to simulate a displacement of a face in the x-direction.
[0050] The geometry decoder 610 can group sets of the instructions to form tasks 603 based on a syntax and schematics of the output tokens 601, as shown above. In some embodiments, the tasks 603 can correspond to part design tasks, such as part selection tasks, feature tasks to identify feature, entity tasks, or the like, which can provide various predictions for part, assembly, manufacture characteristic to a mechanical design tool developing the mechanical design for a product.
[0051] The multi-domain decoding system 600 can include a translation system 620 can convert the tasks 603 into a configuration capable of implementation by the mechanical design tool developing the mechanical design for a product. In some embodiments, the tasks 603 generated by the geometry decoder 610 can be represented at a tool-agnostic level of abstraction, and the domain translation system 620 can convert the tasks into a format capable of execution or consumption by the mechanical design tool.
[0052] Referring back to Figure 3, the mechanical CAD system 340 can include a toolspecific interpreting system 342 to parse tasks specified in the FxL format and convert them into tool-specific features. In some embodiments, when the mechanical CAD system202421203 340 includes an NX CAD tool, the tool-specific interpreting system 342 can include an interpretation system specific to the NX CAD tool, for example, that can use NXOpen Python code to materialize the features specified in an FxL format into NX specific features. When the mechanical CAD system 340 includes a SolidEdge tool, the specific interpreting system 342 can include an interpretation system specific to the Solid Edge tool, for example, that can use C# code to materialize the features specified in an FxL format into SolidEdge-specific features. After these tool-specific features have been created by the tool-specific interpreting system 342, the corresponding tools included in the mechanical CAD system 340 can transform the tool- specific features into models available for implementation and / or user- interaction during design of mechanical part and / or systems in those tools.
[0053] The system and apparatus described above may use dedicated processor systems, micro controllers, programmable logic devices, microprocessors, or any combination thereof, to perform some or all of the operations described herein. Some of the operations described above may be implemented in software and other operations may be implemented in hardware. Any of the operations, processes, and / or methods described herein may be performed by an apparatus, a device, and / or a system substantially similar to those as described herein and with reference to the illustrated figures.
[0054] The processing device may execute instructions or "code" stored in memory. The memory may store data as well. The processing device may include, but may not be limited to, an analog processor, a digital processor, a microprocessor, a multi-core processor, a processor array, a network processor, or the like. The processing device may be part of an202421203 integrated control system or system manager, or may be provided as a portable electronic device configured to interface with a networked system either locally or remotely via wireless transmission.
[0055] The processor memory may be integrated together with the processing device, for example RAM or FLASH memory disposed within an integrated circuit microprocessor or the like. In other examples, the memory may comprise an independent device, such as an external disk drive, a storage array, a portable FLASH key fob, or the like. The memory and processing device may be operatively coupled together, or in communication with each other, for example by an I / O port, a network connection, or the like, and the processing device may read a file stored on the memory. Associated memory may be "read only" by design (ROM) by virtue of permission settings, or not. Other examples of memory may include, but may not be limited to, WORM, EPROM, EEPROM, FLASH, or the like, which may be implemented in solid state semiconductor devices. Other memories may comprise moving parts, such as a known rotating disk drive. All such memories may be "machine-readable" and may be readable by a processing device.
[0056] Operating instructions or commands may be implemented or embodied in tangible forms of stored computer software (also known as "computer program" or "code"). Programs, or code, may be stored in a digital memory and may be read by the processing device. “Computer-readable storage medium" (or alternatively, "machine-readable storage medium") may include all of the foregoing types of memory, as well as new technologies of the future, as long as the memory may be capable of storing digital information in the nature of a computer program or other data, at least temporarily, and as long at the stored202421203 information may be "read" by an appropriate processing device. The term "computer-readable" may not be limited to the historical usage of "computer" to imply a complete mainframe, mini- computer, desktop or even laptop computer. Rather, "computer-readable" may comprise storage medium that may be readable by a processor, a processing device, or any computing system. Such media may be any available media that may be locally and / or remotely accessible by a computer or a processor, and may include volatile and non-volatile media, and removable and non- removable media, or any combination thereof.
[0057] A program stored in a computer-readable storage medium may comprise a computer program product. For example, a storage medium may be used as a convenient means to store or transport a computer program. For the sake of convenience, the operations may be described as various interconnected or coupled functional blocks or diagrams. However, there may be cases where these functional blocks or diagrams may be equivalently aggregated into a single logic device, program or operation with unclear boundaries.Conclusion
[0058] While the application describes specific examples of carrying out embodiments, those skilled in the art will appreciate that there are numerous variations and permutations of the above described systems and techniques that fall within the spirit and scope of the invention as set forth in the appended claims. For example, while some of the specific terminology has been employed above to refer to electronic design automation processes, it should be appreciated that various examples may be implemented using any electronic system.202421203
[0059] One of skill in the art will also recognize that the concepts taught herein can be tailored to a particular application in many other ways. In particular, those skilled in the art will recognize that the illustrated examples are but one of many alternative implementations that will become apparent upon reading this disclosure.
[0060] Although the specification may refer to “an”, “one”, “another”, or “some” example(s) in several locations, this does not necessarily mean that each such reference is to the same example(s), or that the feature only applies to a single example.
Claims
202421203CLAIMS1. A method comprising:analyzing, by a computing system, a geometric representation of a mechanical part to identify a topological connectivity for faces and edges of the mechanical part;sampling, by the computing system, the faces and the edges of the mechanical part described in the geometric representation of the mechanical part;separately encoding, by the computing system, the samples of the faces and the edges of the mechanical part into geometric tokens;combining, by the computing system, the geometric tokens according to the topological connectivity for the faces and the edges in the mechanical part; and utilizing, by the machine-learning algorithm implemented by the computing system, the combined geometric tokens to generate output tokens that, when decoded, correspond to one or more tasks configured for implementation by a mechanical design tool developing a mechanical design including the mechanical part.
2. The method of claim 1, further comprising:generating, by the computing system, a graph corresponding to the topological connectivity of the mechanical part, which includes nodes corresponding to the faces of the mechanical part and includes edges corresponding to the edges of the mechanical part; and utilizing, by the computing system, the graph to arrange the geometric tokens according to the topological connectivity of the mechanical part.202421203 3. The method of claim 1, wherein sampling the faces of the mechanical part further comprises sampling facets of the faces defined by a tessellation associated with the faces of the mechanical part or sampling points on the faces defined by the sampling grid associated with the faces of the mechanical part.
4. The method of claim 1, further comprising selecting a sampling type for the faces and the edges of the mechanical part based, at least in part, on which geometric token encoders are implemented by the computing system, wherein sampling the faces and the edges of the mechanical part described in the geometric representation of the mechanical part is performed with encoders implementing the selected sampling type.
5. The method of claim 1, wherein the output tokens include multiple token series that each correspond to different tasks, and further comprising:determining, by the computing system, a type of mechanical design tool to implement the tasks from the output tokens; anddecoding, by the computing system, the token series into their corresponding tasks, wherein the decoded tasks are configured for implementation by the selected type of mechanical design tool.
6. The method of claim 5, wherein the output tokens specify the tasks in a declarative foundation language that is agnostic of the type of mechanical design tool to implement the tasks and is configured to capture one or more of design intent, functional202421203 features, assemblies, drafting, manufacturing, simulation, and model-based design to geometric elements associated with the tasks.
7. The method of claim 5, wherein the tasks in the token series are defined based on the semantics and syntax of the output tokens in their respective token series.
8. An apparatus comprising at least one computer-readable memory device storing instructions configured to cause one or more processing devices to perform operations comprising:analyzing a geometric representation of a mechanical part to identify a topological connectivity for faces and edges of the mechanical part;sampling the faces and the edges of the mechanical part described in the geometric representation of the mechanical part;separately encoding the samples of the faces and the edges of the mechanical part into geometric tokens;combining the geometric tokens according to the topological connectivity for the faces and the edges in the mechanical part; andutilizing, by a machine-learning algorithm implemented by the one or more processing devices, the combined geometric tokens to generate output tokens that, when decoded, correspond to one or more tasks configured for implementation by a mechanical design tool developing a mechanical design including the mechanical part.202421203 9. The apparatus of claim 8, wherein the instructions are configured to cause one or more processing devices to perform operations further comprises:generating a graph corresponding to the topological connectivity of the mechanical part, which includes nodes corresponding to the faces of the mechanical part and includes edges corresponding to the edges of the mechanical part; andutilizing the graph to arrange the geometric tokens according to the topological connectivity of the mechanical part.
10. The apparatus of claim 8, wherein the instructions are configured to cause one or more processing devices to perform operations further comprises sampling the faces of the mechanical part by sampling facets of the faces defined by a tessellation associated with the faces of the mechanical part or sampling points on the faces defined by the sampling grid associated with the faces of the mechanical part.
11. The apparatus of claim 8, wherein the instructions are configured to cause one or more processing devices to perform operations further comprises selecting a sampling type for the faces and the edges of the mechanical part based, at least in part, on which geometric token encoders are implemented by the computing system, wherein sampling the faces and the edges of the mechanical part described in the geometric representation of the mechanical part is performed with encoders implementing the selected sampling type.202421203 12. The apparatus of claim 8, wherein the output tokens include multiple token series that each correspond to different tasks, and wherein the instructions are configured to cause one or more processing devices to perform operations further comprises:determining a type of mechanical design tool to implement the tasks from the output tokens; anddecoding the token series into their corresponding tasks, wherein the decoded tasks are configured for implementation by the selected type of mechanical design tool.
13. The apparatus of claim 12, wherein the output tokens specify the tasks in a declarative foundation language that is agnostic of the type of mechanical design tool to implement the tasks and is configured to capture one or more of design intent, functional features, assemblies, drafting, manufacturing, simulation, and model-based design to geometric elements associated with the tasks.
14. The apparatus of claim 12, wherein the tasks in the token series are defined based on the semantics and syntax of the output tokens in their respective token series.
15. A system comprising:a memory system configured to store computer-executable instructions; and a computing system, in response to execution of the computer-executable instructions, is configured to:analyze a geometric representation of a mechanical part to identify a topological connectivity for faces and edges of the mechanical part;202421203 sample the faces and the edges of the mechanical part described in the geometric representation of the mechanical part;separately encode the samples of the faces and the edges of the mechanical part into geometric tokens;combine the geometric tokens according to the topological connectivity for the faces and the edges in the mechanical part; andutilize, by a machine-learning algorithm implemented by the computing system, the combined geometric tokens to generate output tokens that, when decoded, correspond to one or more tasks configured for implementation by a mechanical design tool developing a mechanical design including the mechanical part.
16. The system of claim 15, wherein the computing system, in response to execution of the computer-executable instructions, is further configured to:generate a graph corresponding to the topological connectivity of the mechanical part, which includes nodes corresponding to the faces of the mechanical part and includes edges corresponding to the edges of the mechanical part; andutilize the graph to arrange the geometric tokens according to the topological connectivity of the mechanical part.
17. The system of claim 15, wherein the computing system, in response to execution of the computer-executable instructions, is further configured to sample the faces of the mechanical part by sampling facets of the faces defined by a tessellation associated with the202421203 faces of the mechanical part or sampling points on the faces defined by the sampling grid associated with the faces of the mechanical part.
18. The system of claim 15, wherein the computing system, in response to execution of the computer-executable instructions, is further configured to:select a sampling type for the faces and the edges of the mechanical part based, at least in part, on which geometric token encoders are implemented by the computing system; andsample the faces and the edges of the mechanical part described in the geometric representation of the mechanical part with the geometric token encoders implementing the selected sampling type.
19. The system of claim 15, wherein the output tokens include multiple token series that each correspond to different tasks, and wherein the computing system, in response to execution of the computer-executable instructions, is further configured to:determine a type of mechanical design tool to implement the tasks from the output tokens; anddecode the token series into their corresponding tasks, wherein the decoded tasks are configured for implementation by the selected type of mechanical design tool.
20. The system of claim 19, wherein the tasks in the token series are defined based on the semantics and syntax of the output tokens in their respective token series.