JP6604655B2 - Method and system for incremental search for design changes in large-scale computer-aided design models - Google Patents

Description

RELATED APPLICATION This application claims priority and benefit of US patent application Ser. No. 14 / 298,627, filed Jun. 6, 2014, the contents of which are hereby incorporated by reference in their entirety.

  A component-based modeling environment is a modeling environment that can be used to build a high-level model made up of one or more elements called “components” or “component models”. A component model may represent a single unit that can be combined to form a superior model. Component-based modeling can be used to design, model, test and / or visualize products. Component based modeling environments include computer aided design (CAD) and computer aided manufacturing (CAM) environments.

  A component model can be a stand-alone component that does not include separate internal components, or a component model can be composed of one or more components. Different supermodels may use the same component, and a single supermodel may use different components to represent different versions of a single part. Each component can be stored on the storage device as a separate file.

  With traditional methods, especially when developing complex systems with many interdependent components, changing components in a model design is a technique to search for new ideas or design changes. It is a typical problem. For example, changing a model design can be done by manually backing up existing component model files to one or more folders, opening and closing multiple sessions, and repetitively reviewing different models. And may involve evaluation. This process can be very cumbersome and difficult for the user to manage. This process can require that some component model files associated with that model be saved with minor modifications to the model and that each component of that model be rebuilt to implement the design changes. It can also result in wasted storage space and processing resources.

  Moreover, after making changes to one component, other related components in the assembly may also need to be updated to remain consistent with the rest of the assembly. For example, if the user is building a car model and the user changes the width of the car chassis, it may also be necessary to change the axle length in order to be consistent with the modified assembly. Such an implicit change to the dependent component model may be referred to as a derived change.

  When an explicit change is made to one or more components of the model, the entire model may need to be updated to propagate the derivative changes to other components. One of the challenges of model design is managing and gradually designing changes and exploration (i.e., trying one change to update the design and returning some of the changes that caused undesirable derivative changes) Is to control. It can be very difficult to accurately track which derivative changes are caused by which explicit changes and which components are modified with each incremental change. This challenge can make it very difficult to return the model to its previous state neatly.

  This application describes methods, media and systems for performing and evaluating model changes in an efficient, concise and user-friendly manner. According to an example embodiment, a checkpoint may be created when a user changes the model. Changes can be made within a special type of editing session called a “design session” that can include multiple models. Each checkpoint may store changes made to the model since the previous checkpoint and references to the previous checkpoint (eg, pointers). Checkpoints can also include paths to unmodified component models (eg, on local or remote storage) so that components of models that have not been modified since the previous checkpoint need not be duplicated .

  Users are free to create new checkpoints, return to previous checkpoints, split a series of checkpoints into separate sequences, and checkpoint a model that is used as the official working version of the model. You can select the version you want. In this way, users can easily change models to evaluate design changes or different potential evolutions, while at the same time saving storage space by avoiding the need to repeatedly save different versions of the model .

  According to an example embodiment, a request to create a checkpoint for a design session may be received. As described above, a design session may include one or more models. A previous state of the model (s) in the design session can be identified and a list of changes made to the model (s) since the previously saved state can be obtained. A checkpoint may be created, which includes a reference to the previously saved state of the model (s) and a list of component models that have changed since the previously saved state. The reference to the previously saved state of the model can be, for example, a pointer to a second checkpoint and / or a pointer to an unchanged component model.

  The list of changed component models may include component models that are affected by explicit and derivative changes. In some embodiments, instructions for changing the first component of the model may be received. The model can be changed based on the instructions, resulting in an explicit change to the model. Derivative changes to the second component model of the model can be identified. Derivative changes can result from explicit changes, not user instructions to change the second component model, but instead (for example) the parameter relationship between the first component model and the second component model Can be attributed to

  In one embodiment, checkpoints can be created within a design session. Upon entering the design session, one or more basic models may be identified. The base model can be an unmodified model that is edited during the design session. An entry checkpoint can be created that includes a basic model. Subsequent checkpoints can be created and stored within the tree structure, where the entry checkpoint represents the root of the tree structure.

  The basic model and checkpoint (s) can be stored in a design file on the first computer. The design file can be distributed to a second computer and opened on the second computer and used to create a model consistent with the checkpoint.

  According to a further example embodiment, the model may be restored to a state that matches the saved checkpoint. For example, a request to return the model to a saved state can be received. A checkpoint can be obtained that matches the saved state, which includes a reference to a previous checkpoint and / or an unchanged component model and a list of component models that have changed since the previous checkpoint. . Previous checkpoints can be processed to obtain a previous version of the model, and the component model in the list of modified component models is applied to the previous version to return the model to the requested saved state. obtain.

  The previous checkpoint can be, for example, an entry checkpoint associated with the base model, in which case the base model is used as the previous version of the model. Alternatively or in addition, the previous checkpoint is a reference to the second previous checkpoint, and a list of component models that have changed in the model between the previous checkpoint and the second previous checkpoint. Can be included. In general, returning a model to a saved state involves obtaining a base model associated with the entry checkpoint and a series of ones between the entry checkpoint and the checkpoint associated with the saved state. It may involve acquiring the above checkpoints. A series of checkpoints may include a collection of one or more modified component models. The modified component model can be applied to the base model to return the model to a saved state.

  In some embodiments, returning the model to a saved state replaces only the component model that has changed since the previous checkpoint, while maintaining the component model that has not changed since the previous checkpoint. Can be accompanied. As a result, storage space and processing resources can be saved.

  The list of modified component models includes models and / or as a result of explicit changes in accordance with explicit instructions for changing the component model, and explicit changes to satisfy one or more parameter constraints on the model. Or it may include a component model that has been modified by derivative changes made to the components of the model.

  In a further embodiment, a model in a first state may be provided, the model having a first component. One or more changes to the first state of the model may be tracked. For example, instructions for causing an explicit change to the first component may be identified, and the changed component is recorded in the list of changed components. A related component associated with the first component may be identified based on derivative changes to the related component. Derivative changes can be caused by explicit changes. Related components that have changed due to derivative changes may be recorded in the list of changed components. The list of changed components can be used to create a checkpoint.

  Related components may be identified in various ways. For example, related components can be identified by examining parameter constraints associated with the model. Alternatively or additionally, the first component can be analyzed for connections to other components, and the other connected components can be treated as related components.

  Once identified, the identification of the associated component can be stored along with the list of changed components. The first component may also be stored with a list of related components that are related to the first component by a parameter relationship.

Example embodiments are described in more detail with respect to the drawings described below.
This specification provides the following items, for example.
(Item 1)
A non-transitory computer readable storage medium storing instructions, wherein the instructions, when executed by a processor, are stored in the processor
Receiving a request to create a checkpoint for one or more models;
Identifying a previously saved state of the model;
Identifying one or more components that have changed in the model since the previously saved state of the model;
Creating a checkpoint, wherein the checkpoint is
A reference to the previously stored state of the model;
A list of the one or more components that have changed in the model since the previously saved state of the model;
Including, that and
The medium that causes
(Item 2)
The medium of claim 1, wherein the checkpoint further comprises content system cache information including the previously saved state of the model and parameters associated with the model.
(Item 3)
The instructions to the processor;
Entering the design session,
Identifying a basic model to be used as an unchanged model for the design session;
Creating an entry checkpoint consisting of the basic model;
The medium according to item 1, wherein the medium is further executed.
(Item 4)
Item 4. The medium of item 3, wherein the checkpoint is represented as a tree structure and the entry checkpoint represents a root of the tree structure.
(Item 5)
Save the basic model and the checkpoint in a design session file on a first computer
4. The medium of item 3, further storing instructions for.
(Item 6)
Opening the design session file on a second computer;
Creating a model on the second computer that matches the checkpoint;
6. The medium of item 5, further comprising instructions for performing.
(Item 7)
Receiving an instruction to modify a first component of the model;
Modifying the model based on the instructions to provide an explicit change to the model;
Identifying a derivative change to a second component of the model, wherein the derivative change results from the explicit change, and in a user instruction to modify the second component Not caused,
Storing references to the first component and the second component in the list of the one or more components that have changed in the model since the previously saved state of the model;
Item 4. The medium according to Item 1, further storing instructions for performing the operation.
(Item 8)
8. The medium of item 7, wherein the derivative change is based on a parameter relationship between the first component and the second component.
(Item 9)
The medium of item 1, wherein the reference to the previously saved state of the model includes a pointer to a second checkpoint.
(Item 10)
A method,
Receiving a request to return the model to a saved state, wherein the model includes a component;
Obtaining a checkpoint associated with the saved state, wherein the checkpoint is a reference to a previous checkpoint and a modified component in the model that has been modified since the previous checkpoint; Including a list of
Processing the previous checkpoint to compare the previous checkpoint with the current state of the model, wherein the processing is such that the component of the model is in the list of changed components; Including identifying, and
Modifying the component in the model based on a list of modified components to return the model to the saved state, wherein the application is performed using a processor of a computing device. And that
Including a method.
(Item 11)
Returning the model to the saved state replaces only the components of the model that have changed since the previous checkpoint, while any of the models that have not been changed since the previous checkpoint. The method of item 10, comprising maintaining the component.
(Item 12)
11. The method of item 10, wherein the previous checkpoint is an entry checkpoint associated with a basic model, and the basic model is used as the previous version of the model.
(Item 13)
Processing the previous checkpoint includes: a second previous checkpoint; and a list of components modified in the model between the previous checkpoint and the second previous checkpoint. 11. The method according to item 10, comprising obtaining.
(Item 14)
Returning the model to the stored state;
Getting the basic model associated with the entry checkpoint;
Obtaining a series of one or more checkpoints between the entry checkpoint and the checkpoint associated with the saved state, wherein the series of checkpoints has been modified by one or more Including a collection of components,
Identifying a component in the model corresponding to the changed component;
Replacing the identified component with the modified component relative to the base model;
The method according to item 10, comprising:
(Item 15)
The list of modified components is
A first component modified by an explicit change made to the model by an explicit instruction to change the model;
A second component modified by a derivative modification made to the model as a result of the explicit modification to satisfy one or more parameter constraints on the model;
The method according to item 10, comprising:
(Item 16)
A system,
A non-transitory computer readable storage medium storing a model in a first state, wherein the model in the first state includes a first component;
A processor programmed to track one or more changes made to the model in a first state, tracking the one or more changes;
Identifying an instruction that causes the first component to cause an explicit change;
Recording the explicit change in a list of changes;
Identifying a related component associated with the first component based on a derivative change to the associated component caused by the explicit change;
Receiving a request to create a checkpoint for the model;
Creating the checkpoint, wherein the checkpoint is
A reference to the previously saved state of the model;
A list of modified components including the first component and the associated component;
Including, that and
Including, processor and
With a system.
(Item 17)
The system of claim 16, wherein identifying the relevant component includes examining parameter constraints associated with the model.
(Item 18)
The system of claim 16, wherein tracking the one or more changes includes storing an identification of the related component along with the list of changed components.
(Item 19)
The system of claim 16, wherein the first component is stored with the list of related components.
(Item 20)
The system of claim 16, wherein identifying the relevant component comprises analyzing the first component for linkage to other features.

An example of checkpointing in a component-based modeling environment is shown. An example of checkpointing in a component-based modeling environment is shown. An example of checkpointing in a component-based modeling environment is shown. An example of checkpointing in a component-based modeling environment is shown. An example of checkpointing in a component-based modeling environment is shown. An example of checkpointing in a component-based modeling environment is shown. An example of checkpointing in a component-based modeling environment is shown. FIG. 4 illustrates an example modeling environment suitable for use with the example embodiments described herein. FIG. 4 illustrates an example checkpoint tree for searching and evaluating design changes for a component, assembly, or model, according to an example embodiment. 4 illustrates an example change database for tracking changes to components in a model in a component-based modeling environment, according to an example embodiment. 6 is a flow diagram illustrating an example method for creating a checkpoint according to an example embodiment. Fig. 4 illustrates an example checkpoint data structure suitable for use in an example embodiment. 5 is a flow diagram illustrating an example method for restoring a component, assembly, or model from a checkpoint according to an example embodiment. FIG. 4 illustrates an example computing device suitable for use with the example embodiments described herein. FIG. FIG. 6 illustrates an example network implementation suitable for use with the example embodiments described herein.

  For ease of discussion, throughout this specification, specific examples may be presented with reference to the Creo® product family from PTC®, Needham, Massachusetts. One skilled in the art will appreciate that the example embodiments described herein are not limited to a particular product family, but can be applied in any suitable component-based modeling environment. Furthermore, although this application describes a model that is composed of component models, it should be noted that the present invention is not so limited. For example, a user may manipulate a model that does not itself contain a component model and create a checkpoint for it.

  In a component-based modeling environment, a user can build a model by defining the shape of the model. The shape that makes up the model can consist of a collection of surfaces that can be joined by edges that meet at the contacts.

  A shape can represent a component of a model, which can take a wide variety of shapes or sizes. A combined set of surfaces, edges, and contacts can define a component in the model, which can be viewed as a stand-alone element on which a component-based model can be built. A component can be a separable part of a model stored in a file on a storage medium and can participate in a given higher level model. A collection of combined components can be referred to as an assembly.

  In addition to shapes, components can also be associated with one or more parameters and one or more relationships such as mathematical functions. Parameters and relationships may define shapes or dimensions and shapes relationships. Components can be defined in terms of a two-dimensional space, a three-dimensional space, or both.

  Component-based modeling environments generally provide tools for manipulating component shapes. Examples of tools include an extrude tool that moves a surface or part of a surface in 2D or 3D space, and selected edges and contacts to zoom in or out on the entire surface or component. Includes a stretch tool that moves in a specific direction.

  A user may instruct the modeling environment to make changes to a component (eg, by applying one of a tool or a set of tools and / or actions). Such a change is referred to herein as an explicit change. An explicit change can also cause a derivative change in another component of the model that is related by a parameter relationship to the changed component. A parameter relationship may be a relationship between two or more components based on one or more parameters associated with those components. A parametric relationship can occur as a result of concatenating two or more components, or can be defined (manually or automatically) by parameter constraints. The parameter constraint may define a limit on the parameters of the second component with respect to the parameters of the first component. For example, the user may indicate to the chair model that the width of the base component of the chair is within a percentage or ratio (eg, 95%) of the chair seat component, or within a range of the percentage or ratio. Parameter constraints can be defined.

  Manipulating the shape of a component can result in one or more changes (either explicit or derivative) to the component. A user may wish to evaluate a number of different design changes for a particular component or components before committing the use of a particular change in the model. For example, a user may wish to make an explicit change to one component of the model to determine whether the explicit change results in an undesirable derivative change. Further, the user may wish to save different changes or versions, including changes or versions that have been removed from consideration for future reevaluation of the changes or versions.

  As a result, the example embodiments described herein enable checkpoints to be created. Checkpoints capture different design changes / versions in an efficient manner, and for each change / version you evaluate, you do not have to use the means of manually saving the entire assembly of components in a new file. Changes / versions can be quickly and easily restored.

  Checkpoints can be created during a session of a component-based modeling environment. A session may represent a period of time during which the model can be manipulated. Multiple models stored in multiple files can be manipulated within a single session, and multiple different sessions can be active at one time. A session can be manually started and / or ended by the user by instructing the modeling environment to start / end the session. Alternatively or additionally, a session can be automatically started or ended when certain conditions occur (eg, launching or closing a component-based modeling environment).

  In some example embodiments described herein, a special type of session called a design session may be initiated and terminated. A design session may represent a period of time during which a model can be changed in various ways, and the changes can be checkpointed to create different versions of the components of the model. One or more of the checkpoints can be selected as the official version (s) of the model design and can be incorporated into the model in a general session. Different versions can be stored in the design session file, which can be shared among users on the same or different computers so that the different versions can be reviewed and evaluated by the design team.

  Checkpoints created in a design session may include or point to modified models (eg, different versions or changes tried during the design session). In some embodiments, the modified model can only be found within the design session (e.g., the modified model and design session information is stored in a special design session file or temporary runtime extraction folder). obtain).

  It will be appreciated that checkpointing does not necessarily have to occur within a designated design session and may be generally applicable to component-based modeling environments. In addition, for ease of explanation, examples are described below with respect to a single model being edited within a design session. However, the present invention is not limited to the use of a single model within a design session, and those skilled in the art will appreciate that multiple models can be represented within a single design session.

  The use of checkpointing in a component-based modeling environment will be more clearly understood with reference to a non-limiting example. 1A-1G show an example of checkpointing used in such an environment.

  As shown in FIG. 1A, a model 110 may be created in a modeling environment. The model 110 can be a physical model composed of various components. In the example of FIG. 1A, the model 110 represents a chair having two armrest components 112, four wheel components 114, and a base component 116, among other components.

  The modeling environment may also include a component list 118 that allows components to be selected, displayed, captured, replaced, or deleted within the model 110. The modeling environment may also support a checkpoint tree representation 120 that displays checkpoints created within the current session.

  The checkpoint tree representation 120 may include a checkpoint hierarchy. Checkpoints can be stored hierarchically in the database. The checkpoint tree representation 120 represents checkpoints from the database as a flat timeline (potentially, different colors, etc. to represent different sequences of checkpoints, among other possibilities). (With distinguishing features) or as a tree. When checkpoints are displayed as a tree, the tree can be organized as a hierarchy of checkpoint sequences or branches, in which case the split points can be expandable nodes. The branches may be switchable to display as main branches and / or to list vertically to save graphics space.

  Checkpoint tree representation 120 may include entry checkpoints 122 that represent the initial configuration of model 110. For example, the entry checkpoint 122 may represent the state of the model when the current session starts. This initial state of the model can be called the basic model.

  During the session, the model 110 may be changed as shown in FIG. 1B. In this example, the armrest component 112 is modified to connect to the back of the chair, not the seat.

  As changes are made to the model 110, the user may create a checkpoint that represents the current state of the model 110. As shown in FIG. 1C, when instructing the modeling environment to create a checkpoint, the modeling environment may display a checkpoint dialog 124 for entering information regarding the current checkpoint. The checkpoint dialog includes a checkpoint name 126 displayed in the checkpoint tree representation 120, a searchable keyword 128 that allows the user to search between different checkpoints in the checkpoint tree representation 120, and future references. May include a field for creating a checkpoint comment 130 that allows the user to describe the checkpoint.

  As shown in FIG. 1D, after creating a new checkpoint, checkpoint 132 may be shown in checkpoint tree representation 120. The user can then continue editing the model 110 from the new checkpoint or return to a different checkpoint to search for different design changes.

  In the example shown in FIG. 1E, the user continues to edit the model 110 from the first checkpoint. In this case, the user has changed the model 110 to include the fifth wheel component 114. The user may create a second checkpoint 134 that captures the state of the model with the updated armrest component 112 and the updated wheel component 114.

  If the user wants to return to a previously saved checkpoint (eg, first checkpoint 132), that checkpoint may be selected in checkpoint tree representation 120. As shown in FIG. 1F, upon selecting a previous checkpoint, a restore option 136 may be displayed. If the user selects the restore option 136, the model 110 may be restored to a state consistent with the previous checkpoint. In this case, when the restore option 136 associated with the first checkpoint 132 is selected, the model 110 is in a state consistent with the first checkpoint 132 (eg, the state of the model 110 as shown in FIG. 1B). Will be returned to.

  Checkpoints can be stored separately from one another, or a checkpoint hierarchy can be created. For example, if the user starts at the first checkpoint 132 and further modifies the model 110, a nested checkpoint may be created under the first checkpoint 132. In FIG. 1G, the user has changed the model 110 from the first checkpoint 132 to incorporate a larger base component 116. A nested checkpoint 138 is created under the first checkpoint 132 and shown in the checkpoint tree representation 120. Nesting checkpoints in this way can be useful to provide a visual indication of the relationship between checkpoints. By representing checkpoints as a hierarchy, design changes and processes can be captured more accurately and efficiently. For example, different branches in the hierarchy can be used to represent different sequences of divisions in the design process and / or changes in the model.

  The user may also delete checkpoints that are no longer needed. When a checkpoint in the checkpoint hierarchy is deleted, the information in the deleted checkpoint (such as saved component models and references to previous checkpoints) is removed before the deleted checkpoint is removed. Can be integrated with later checkpoints. Thus, the checkpoint tree structure can be maintained without loss of information.

  FIG. 2 illustrates an example modeling environment 200 for checkpoint creation and management. An example of a modeling environment 200 is PTC Inc., located in Needham, Massachusetts. Creo® Parametric. Modeling environment 200 may reside on a local computing device or be accessed through a network.

  The model 110 may exist within the modeling environment 200. The model 110 may include one or more assemblies, each assembly being constructed with one or more component models. Modeling environment 200 may provide a tool for modifying model 110.

  When the model 110 is changed, the model may include one or more changed components 212 and one or more unchanged components 214. The modeling environment 200 may track which components have changed and which have not changed in order to create checkpoints described below. In order to keep track of which components have changed and how those components have changed, the modeling environment 200 may include change logic 220 for detecting changes. For example, the change logic 220 may analyze incoming instructions to the modeling environment 200 to determine which instructions have changed the shape of the component resulting in the changed component 212. Alternatively or additionally, the change logic 220 may periodically compare the current version of the component with the previous version of the component. If the current version does not match the previous version, the change logic may record the component as changed.

  Changes in the shape of components and / or the placement of components relative to each other may be recorded in the change database 230 by the change logic 220. The change database 230 may include a list of changes to the model as well as information about the resulting shape of the changed component 212.

  A user may direct the modeling environment 200 to create a checkpoint at any time for the model 110 (and / or for multiple models 110 edited within a session). Alternatively or additionally, the modeling environment 200 may automatically create checkpoints (eg, at the occurrence of a predetermined event, such as the start of a design session, or at a predetermined time interval). As such, the modeling environment 200 may include checkpoint logic 240 for defining how the checkpoint 250 is created.

  Once checkpoints 252 and 254 are created for the current state of model 110, checkpoints 252 and 254 may be stored in a checkpoint database. The modeling environment 200 may further include checkpoint restoration logic 260, which obtains one or more checkpoints 250 from a checkpoint database and matches the model 110 with the obtained checkpoint (s). Can be restored.

  An example of checkpoints 250 arranged hierarchically in the checkpoint tree is shown in FIG. As shown in FIG. 3, an assembly may be associated with multiple assembly versions 310, each assembly version 310 representing the state of the assembly and the components that make up the assembly. Each assembly version 310 may also be associated with one or more subversions 320 defined within the design session. FIG. 3 shows an example in which the user is working with version 2 of the assembly to create version 3 of the assembly.

  As shown in FIG. 3, the initial version of the assembly (version 2) is taken into the design session and used as the initial “before change” base model 330 for that design session. An entry checkpoint 340 may be created at the start of the design session, which stores the basic model 330 and serves as the root of the checkpoint 250 tree. Multiple checkpoints 250 can be created when the user edits the model, and the user can select one of the checkpoints to be used as the next lower version 320 for the assembly.

  In the example shown in FIG. 3, the user changes the basic model 330 to create a first checkpoint, changes the model associated with the first checkpoint in three different ways, 3 and 4 checkpoints were created. The user then returns to the second checkpoint and uses that checkpoint as the basis for the fifth checkpoint, and then returns to the third checkpoint and uses that checkpoint as the basis for the sixth checkpoint. Used as. Continuing this process, ultimately, the user determined that the sixth checkpoint represents the version of that model that will be used as the next official subversion 320. The user may have iterated further through the lower version 320, but the user decides that the lower version 320 is satisfactory and replaces this lower version with the official version of the assembly (version 3). did.

  In conventional component-based modeling systems, models can be stored as files that are loaded at runtime. As the user makes changes to the model, a new file can be created for the changed component, which can also be stored in (another file). As a result, in the example described above, the user may have created multiple different model save files for each of the 14 checkpoint versions shown.

  In order to restore a previous version of the model, each of the model files associated with the components in the model may need to be reloaded and the components regenerated. For example, files associated with components in the requested version of the model may need to be retrieved from storage and processed to create a new in-memory version of the model. In the above example, in order to evaluate each of the 14 different versions, the user may have loaded the saved file (s) for the selected version, which is the entire model and all of its constituent components. May have reloaded. This consumes a large amount of both storage and processing resources.

  However, the checkpoint 250 shown in FIG. 3 can utilize information in the change database 230 to save and restore only model components that have changed since the previous checkpoint. For example, after obtaining files that relate only to components in a checkpoint that are different from the current version of the model, the current in-memory version of the model can be updated using only the changed components. This can save considerable processing resources because not all of the component files that make up the model need to be loaded and the entire model need not be regenerated.

  In some embodiments, references to changed components (eg, pointers) can be stored within the checkpoints, further reducing the amount of storage space required to store each checkpoint. By storing and processing only those components that have been modified as identified by the change database 230, Checkpoint stores and processes a smaller amount of information than traditional backup techniques. An example of the change database 230 is shown in FIG.

  As shown in FIG. 4, each time an instruction that results in a change to one of the components of the model is received by the modeling environment, information about that instruction may be stored in the change database 230 as a change 410. Additionally, if the instruction causes a derivative change (eg, due to a parameter relationship or parameter constraint), the derivative change may also be recorded in the change database 230 as a change 410.

  The change 410 may include one or more shape changes 412 due to the instructions. Shape change 412 may include, for example, a description of features affected by the change, or edges, contacts, and surfaces. The shape change 412 may include information regarding the new shape due to the change, may include information regarding the previous state of the shape, and / or may include information regarding how the old shape changes to the new shape.

  The change 410 may further include a list 414 of affected components that are affected by the change. Affected components 414 can include components that have been directly modified by the change, and can include a list of related components for which derivative changes can be performed as a result of the current change. Related components may be identified, for example, by examining parameter relationships associated with the model and / or by analyzing components that are linked to changed components in the model.

  The change 410 may further include management information (and potentially session information that provides details about the session in which the change was made), such as a time stamp 416 that describes the time at which the change was made. The change 410 may also include an active checkpoint 418 indicating which checkpoint was being edited when the change was made.

  Further changes 420 can be recorded in the change database in a similar manner.

  Changes in the change database 230 can be used to create checkpoints. An example process for creating a checkpoint is shown in the flowchart of FIG.

  In step 510, a design session may be initiated. A design session can be started automatically, such as when a component-based modeling application is launched, or a new component is brought into the modeling environment, or so that the user initiates a design session (e.g., It can be initiated manually, such as when instructing the modeling environment (by selecting a menu option to enter a design session).

  Optionally, a design session can be loaded from a design session file. In this case, any checkpoint stored in the design session file can be captured in the modeling environment and displayed in the checkpoint tree.

  At step 515, after the start of the design session, the modeling environment may store the current state of any active model as a basic model in the modeling environment. There can be more than one model active during a session. Since the base model existed at the start of the design session, it can represent an unmodified version of the model. An entry checkpoint consisting of a representation of the basic model can be created at this step (without modification).

  It is possible that the components of the basic model already exist on one or more storage devices associated with the modeling environment. In this case, it may be unnecessary to save the component as a basic model (again). Thus, according to example embodiments, at the start of a design session, the modeling environment may store the initial state of the assembly of components as a basic model. This is accomplished by saving links (eg, pointers) to all initial component files on the storage device (s) loaded into the modeling environment rather than saving each component individually. obtain. The modeling environment may save only those components that have changed since the component was loaded into the modeling environment to disk.

  In some embodiments, the base model file (s) or a pointer to the base model file (s) may be stored in an entry checkpoint, and the entry checkpoint is in the design session file associated with the design session. Can be stored. The system may retrieve the basic model file (s) in a hierarchical manner. For example, when searching for the basic model file (s), the system may first search the design session file to find the pre-change model. If the original model file (s) are not found in the design session file, the system may check the current working folder or model workspace and then search in the defined search path. If the model file (s) are not found, an interface may be presented to the user to allow the user to browse manually and search for the model file (s).

  There are several reasons why the entire basic model is not backed up in the design session file if it does not need to be done. First, saving only references (eg pointers) to files already stored on disk reduces the size of the design session file, and several model files are available on their original path In such cases, duplication / redundancy is reduced. Furthermore, if the model file is backed up to a design session file, this can cause naming conflicts (in some situations) when the checkpoint is activated and the base model file is loaded into the model workspace. .

  Nevertheless, in some embodiments, the base model file can be backed up to a design session file. This can be particularly useful, for example, when the design session file is moved to a different computer that does not contain a basic version of the model stored on disk.

  When a design session is loaded from a design session file, an entry checkpoint in the design session file can be loaded and a basic model of the entry checkpoint can be obtained by the modeling environment. If the basic model does not already exist in the modeling environment, the modeling environment can take the basic model from the design session file and load the basic model into the modeling environment. In addition to loading the basic model, the design session file may allow other details of the design session to be restored, such as environmental characteristics. For example, if a first user opens several windows / models to store a design session and a second user opens its associated design session file, the design session file is stored on the second user's computer. A window / model can also be opened above.

  At step 520, the user may optionally request to activate an existing checkpoint. If there is no existing checkpoint, or if the user does not choose to activate the existing checkpoint, the process proceeds directly to step 530. If the user activates an existing checkpoint, processing may proceed to step 525 and the modeling environment may activate the selected checkpoint. An example procedure for activating a checkpoint is described in further detail with respect to FIG.

  Once the desired checkpoint (either an entry checkpoint or a selected checkpoint) is activated, processing can proceed to step 530 and the user can edit the model. As the user makes changes to the model, processing may proceed to step 535 and the modeling environment may determine whether any of the user edits cause changes to the components of the model. Otherwise, processing can return to step 530 until the edit is a change to the component.

  If it is determined at step 535 that the component of the model has been changed, processing may proceed to step 540 where explicit changes caused by user editing may be performed. As changes are made, the modeling environment may analyze related components that depend on the changed components and / or obtain parameter relationships / constraints associated with the changed components. If the explicit change is determined to require a derivative change in the associated component, then at step 545 the derivative change may be performed.

  At step 550, each explicit change and derivative change may be recorded in a change database. At this point, the model has changed and the user can instruct the modeling environment to store the changed model in a checkpoint. Alternatively or additionally, an automatic checkpoint can be triggered at this point. As a result, processing can proceed to step 555 where the modeling environment can determine whether to store the checkpoint.

  If it is determined in step 555 that the checkpoint should be saved (eg, the modeling environment has received an instruction to store the checkpoint, so a predetermined period of time has passed since the last checkpoint was saved). Processing may proceed to step 560 (because it has elapsed or because a predetermined event has occurred). Otherwise, processing can return to step 520 to determine if an existing checkpoint has been activated.

  At step 560, the modeling environment begins a new checkpoint creation process. The modeling environment may determine which checkpoint is currently active. For example, if the user is editing a basic model from an entry checkpoint, the entry checkpoint is considered the currently active checkpoint. If the user activates a different checkpoint at step 520, the activated checkpoint may be considered the currently active checkpoint.

  A reference to the currently active checkpoint may be stored in the new checkpoint. For example, a currently active checkpoint can be represented as a location in memory or on a storage medium. A pointer to the address of the currently active checkpoint can be stored with the new checkpoint at step 560. Processing may then proceed to step 565.

  At step 565, the modeling environment may consult the change database to determine which components have changed since the currently active checkpoint was activated. When the currently active checkpoint (eg, the checkpoint activated at step 525 or the entry checkpoint created at step 515) is activated and a new checkpoint should be stored (eg, at step 555) Any component that has changed since it was determined (as a result of the “YES” determination) can be stored with the new checkpoint.

  Each component can be represented by a component model file. For each changed component, it may be possible, but not necessary, to store the entire component model file in a checkpoint. Rather, the component model file associated with the component can be stored at a known location in memory, and the address of the known location can be saved with the checkpoint (eg, as a pointer). Alternatively or additionally, the name / path of the component model or component model file may be stored in the checkpoint.

  In addition to components, model files, parameters, and other aspects of models used to represent changes can also be stored in checkpoints. For example, if a user moves one component relative to another component in the model (ie, affects the placement of the component in the model), the model file that defines the placement of the component is also stored in the checkpoint. And can be used to restore the model to a state consistent with the checkpoint.

  At step 570, a reference to the previous checkpoint and the creation of a new checkpoint consisting of components that have changed since the previous checkpoint were successful. The checkpoint is made the currently active checkpoint, and processing to determine if the user wants to return to a different checkpoint (or alternatively, to continue editing the currently active checkpoint at step 530) May return to step 520.

  At the end of the design session, any checkpoints created during the design session (including entry checkpoints) may be stored in the design session file. Design session files can be distributed to other computers to allow other users to evaluate design changes captured by checkpoints. If the basic model saved in step 515 contained a reference to a model component stored locally on disk (as described above), there are options for copying the model file from disk to the design session file. Can be presented. Thus, if the design session file is distributed to another computer that does not have a local copy of the basic model, the basic model can be obtained from the design session file.

  One or more checkpoints are created by the method described in FIG. An example of the data structure for the checkpoint is shown in FIG.

  As shown in FIG. 6, the checkpoint created first may be an entry checkpoint 340. An entry checkpoint may consist of a representation of the basic model 330 with no associated modified features.

  After editing the base model 330, additional checkpoints 252 can be created. This checkpoint 252 may include a reference 610 to a previous checkpoint. Reference 610 can be, for example, a pointer. In this case, the check point 252 is created based on the editing on the basic model 330. As a result, reference 610 points back to entry checkpoint 340.

  Checkpoint 252 may further include a list 620 of changed components that have changed since the previous checkpoint. The list may include, among other possibilities, a pointer to the component model file and / or a path to the component model file for the changed component. One or more modified components 622, 624 may be included in the list 620. Additional checkpoints 630 having a reference 632 and a list 634 of changed components 636 may be created as needed. In the example shown in FIG. 6, the second checkpoint 630 is created based on the version model represented by the first checkpoint 252, so that it points back to the first checkpoint 252 through the reference 632. .

  It should be understood that references from multiple different checkpoints may each point to the same previous checkpoint, as in the case of a tree structure where multiple checkpoints share a single parent.

  Once a checkpoint is created, the checkpoint can be activated to restore the model to a state that matches the checkpoint. FIG. 7 shows an example method for activating a checkpoint. Briefly summarized, the procedure described in FIG. 7 recursively returns to an entry checkpoint through the checkpoint hierarchy / tree, using the checkpoint selection, references contained within the checkpoint, Accumulate a list of changed components associated with each checkpoint, consolidate the list of changed components, and get the correct (eg latest) version of the changed components used in the model It involves identifying and only changing those components of the base model that need to be regenerated while maintaining the unchanged components.

  At step 710, the modeling environment may receive a request to activate or restore the identified checkpoint. A checkpoint restoration request may be received, for example, by activating a checkpoint in the checkpoint tree. The checkpoint identified in the request becomes the currently active requested checkpoint.

  At step 715, the modeling environment may create an initially empty list of changed components. As checkpoints are obtained through the procedure described in FIG. 7, the components changed at each checkpoint may be added to the list of changed components.

  At step 720, the modeling environment may obtain the currently requested checkpoint. The checkpoint can be stored, for example, as a data structure in memory, and at step 720, the data structure associated with the identified checkpoint can be accessed. The data structure may include a reference to the previous checkpoint and a list of changes that occurred between the previous checkpoint and the currently active requested checkpoint.

  At step 725, the modeling environment may extract a list of changed components from the requested checkpoint. The list of changed components may represent components that have changed between the currently loaded checkpoint and the previous checkpoint. At step 730, the modified component list obtained from the current checkpoint may be added to the modified component list created at step 715. As changed components are accumulated in the list, the modeling environment may maintain a record of the order in which the components were changed and / or which changed component is the “latest” version of the component (eg, step 710 may represent the latest component version with respect to the requested checkpoint.

  At step 735, the modeling environment may follow a reference to the previous checkpoint obtained from the requested checkpoint. At step 740, the modeling environment determines whether the previous checkpoint is an entry checkpoint. An entry checkpoint can be identified, for example, based on the structure of the entry checkpoint. For example, all non-entry checkpoints may include references to previous checkpoints and a list of changed components. In contrast, an entry checkpoint may contain a representation of the basic model and no modified components.

  If the answer at step 745 is “YES”, then all necessary modified components are identified, and processing may proceed to step 750. If not, further changes need to be accumulated and processing may proceed to step 745.

  In step 745, the previous checkpoint accessed through the reference in the active checkpoint becomes the new current active requested checkpoint. Processing may then return to step 720 where the remaining checkpoints are processed recursively until an entry checkpoint is reached.

  At step 750, all necessary modified components have been accumulated and the modeling environment has identified the entry checkpoint with the base model. The modeling environment may identify a basic model within an entry checkpoint, which may involve extracting a list of components that exist within the basic model.

  At step 755, the modeling environment may examine the list constructed at step 730 to determine which components of the base model have changed between the entry checkpoint and the requested checkpoint. For example, a list of changed components can be integrated so that only the latest version of the component is used (compared to the requested checkpoint).

  Features that have not been changed since the base model was created can be considered as unchanged features. An unmodified feature list can also be created in addition to the modified component list.

  At this point, the system has accumulated a list of the components (unmodified and modified features) that make up the model as represented by the requested checkpoint. The list can be compared to the set of components present in the currently active model loaded in memory. If any of the components matches the version of a component that exists in the currently active model, these components can be left in their current form (thus reducing the need to recreate the model's components To do). At step 760, the modeling environment may obtain the latest version of the component identified in the integrated list from step 755 that does not exist in the currently active model. For example, the modeling environment may obtain a component model file (or component model file version) associated with the latest version of the component identified in the consolidated list and / or the list of unchanged components.

  The component obtained at step 760 can be applied to the model, whereby the obtained component replaces an existing component in the model. Alternatively or in addition, existing components can be removed or acquired components can be added to the model to match the model with the checkpoint.

  In order to match a model with a checkpoint, the acquired components captured in that model are used to maintain or reconstruct parameter dependencies and relationships that exist either at the component level or at the feature / parameter / shape level. They may have their characteristics, parameters, and / or shapes manipulated.

  In some embodiments, only changed components can be replaced to match the model with the checkpoint. After replacement of these components, the system is based on the changed component structure in the updated model, and any components that are related to the changed components (and / or components that have changed due to parameter dependencies or relationships) ) Can be recalculated or regenerated. This may involve making changes to components that already exist in the model and that were not previously regenerated / updated in steps 755-760.

  Processing can then proceed to step 765 and end.

  In some embodiments, it is not necessary to go back to the original entry checkpoint. The model is currently in the state represented by the first checkpoint in the checkpoint tree, and the requested checkpoint is on the same branch as the first checkpoint on the checkpoint tree, before or after If it is a checkpoint, it may be possible to go back only between the first checkpoint and the requested checkpoint and change only the components that have changed between the two checkpoints.

  For example, referring to the example of FIGS. 1D and 1G, the first checkpoint 132 is a chair comprising an armrest component 112 attached to the chair back and a four wheel component 114 attached to the narrow base component 116. expressed. Nested checkpoints 138 (located along the same checkpoint tree branch as the first checkpoint 132) are 4 attached to the armrest component 112 attached to the chair back and the wide base component 116. A chair with two wheel components 114 is represented.

  If the nested checkpoint 138 is a currently active checkpoint and the user decides to activate the first checkpoint 132, the modeling environment determines that these checkpoints are the same in the checkpoint tree. It can be identified that it is located on a branch. By returning from the nested checkpoint 138 to the first checkpoint 132, the modeling environment determines that the only change to the model between these two checkpoints is that the base component 116 has been expanded. Can do. Thus, to return to the first checkpoint 132, it may be sufficient to load only the base component 116 and change any component associated with the base component 116 by a parameter relationship, and thus the chair Maintain most components of the model and change only the width of the base component 116. This can save processing resources when loading a previously checkpointed version of the model.

  An example of creating and restoring checkpoints will now be described.

  Consider an example of a bike assembly stored in a model file “bike.asm”. bike. The asm file includes files representing different parts of the motorcycle (for example, a file “handlebar.prt” representing an operation lever component, a file “front_wheel.asm” representing a front wheel component, a file “rear_wheel.asm” representing a rear wheel component, and Can be stored in an assembly model folder that includes a file “seat.prt”) representing the sheet component. As used in this example, both parts and assemblies can represent components.

  When starting a design session, an entry checkpoint may be created. The entry checkpoint is bike. It may contain a pointer to the original assembly model folder that contains the asm file as the base model.

  Next, when the user changes the shape of the operation lever portion of the motorcycle, handlebar. A new version of the prt file can be generated. The user may indicate that a first checkpoint can be created. Checkpoint 1 includes a reference to the entry checkpoint and handlebar. It may contain a new version of the prt file.

  The user can then change the shape of the front wheel, rear wheel, and seat of the bike to create a new checkpoint. Checkpoint 2 is front_wheel. asm file, rear_wheel. asm file, and seat. It may include a reference to checkpoint 1 as well as a new version of the prt file.

  The user can then change the seat placement for the bike model to create a third checkpoint. Checkpoint 3 is a reference to checkpoint 2 and the bike. Contains a new version of the asm file.

  Now assume that the user closes the design session and exits the modeling environment. The user can then reopen the modeling environment and load some version of the bike from storage. If the user then requests that the bike be restored to a state consistent with checkpoint 3, the modeling environment will handle the handlebar. prt file from checkpoint 1 to front_wheel. asm file, rear_wheel. asm file, and seat. prt file from checkpoint 2 as well as bike. Asm files may be collected from checkpoint 3. Components in the currently active version of the model in memory that do not match these model files can be replaced and regenerated.

  Alternatively, the user may request to restore the third checkpoint without loading the current model into memory. In this case, the modeling environment may load the necessary files based on the base model in the entry checkpoint and the modified components reflected in the subsequent checkpoint.

  One or more of the operations described above may be encoded as computer-executable instructions that can be executed by processing logic. Computer-executable instructions may be stored on one or more non-transitory computer-readable media. One or more of the operations described above may be performed within an appropriately programmed electronic device. FIG. 8 illustrates an example of an electronic device 800 suitable for use in one or more embodiments described herein.

  The electronic device 800 can take many forms, including computers, workstations, servers, network computers, quantum computers, optical computers, Internet appliances, mobile devices, pagers, tablet computers, smart sensors, application-specific processing devices, etc. Including but not limited to.

  The electronic device 800 is exemplary and may take other forms. For example, alternative embodiments of electronic device 800 may have fewer, more components, or differently configured components than the configuration of FIG. The components of FIG. 8 and / or other drawings described herein include logic that is hardware-based logic, software-based logic, and / or a combination of hardware and software-based logic (eg, hybrid logic). The components illustrated in FIG. 6 and / or other drawings may not be limited to a particular type of logic.

  The processor 802 may include hardware-based logic or a combination of hardware-based logic and software to execute instructions on behalf of the electronic device 800. The processor 802 may include logic that may interpret, execute, and / or otherwise process information contained in the memory 804, for example. Information may include computer-executable instructions and / or data that may implement one or more embodiments of the invention. The processor 802 may include a variety of similar or dissimilar hardware. The hardware may be, for example, one or more processors, a microprocessor, a field programmable gate array (FPGA), an application specific instruction set processor (ASIP), an application specific integrated circuit (ASIC), a complex programmable logic circuit (CPLD). , A graphics processing unit (GPU), or any combination of other types of processing logic that can interpret, execute, manipulate, and / or otherwise process information. The processor may include a single core or multiple cores 803. Further, the processor 802 may include a system on chip (SoC) or a system in package (SiP). An example of the processor 802 is an Intel® Core ™ series processor available from Intel Corporation of Santa Clara, California.

  The electronic device 800 may include one or more tangible non-transitory computer readable storage media for storing one or more computer-executable instructions or software that may implement one or more embodiments of the invention. The non-transitory computer readable storage medium can be, for example, memory 804 or storage device 818. Memory 804 may include a RAM that may include a RAM device that may store information. A RAM device can be volatile or non-volatile, for example, one or more DRAM devices, flash memory devices, SRAM devices, zero capacitor RAM (ZRAM) devices, twin transistor RAM (TTRAM) devices, read only memory (ROM). ) Devices, ferroelectric RAM (FeRAM) devices, magnetoresistive RAM (MRAM) devices, phase change memory RAM (PRAM) devices, or other types of RAM devices.

  One or more computing devices 800 may include a virtual machine (VM) 804 for executing instructions loaded in memory 804. A virtual machine 806 may be provided to handle processes executing on multiple processors, so that the process appears to be using only one computing resource rather than multiple computing resources. obtain. Virtualization can be utilized within the electronic device 800 such that infrastructure and resources within the electronic device can be dynamically shared. Multiple VMs 806 may reside on a single computing device 800.

  The hardware accelerator 808 may be implemented in an ASIC, FPGA, or some other device. The hardware accelerator 808 can be used to reduce the general processing time of the electronic device 800.

  The electronic device 800 may include a network interface 810 for connecting through various connections to a local area network (LAN), a wide area network (WAN), or the Internet, including a standard telephone line, LAN or WAN link (eg, T1, T3, 56 kb, X.25), broadband connection (eg, Integrated Services Digital Network (ISDN), Frame Relay, Asynchronous Transfer Mode (ATM), wireless connection (eg, 802.11), The network interface 708 includes a built-in network interface including, but not limited to, high speed interconnects (eg, InfiniBand, Gigabit Ethernet, Myrinet) or any combination of any or all of the above. Network, network interface card, personal computer memory card international association (PCMCIA) network card, card bus network adapter, wireless network adapter, universal serial bus (USB) network adapter, modem, or electronic device 800 for any type of networkable communication And any other device suitable for performing the operations described herein.

  The electronic device 800 may include one or more input devices 812, for example, a keyboard, a multipoint touch interface, a pointing device (eg, a mouse), a gyroscope, an acceleration that may be used to receive input from a user A meter, a haptic device, a tactile device, a neural device, a microphone, or a camera. Note that the electronic device 800 may include other suitable input / output peripherals.

  Input device 812 may allow a user to provide input that is registered on visual display device 814. A graphical user interface (GUI) 816 may be displayed on the display device 814.

  A storage device 818 may also be associated with the computer 800. Storage device 818 may be accessible to processor 802 via an input / output bus. Information in storage device 818 may be executed, interpreted, manipulated, and / or otherwise processed by processor 802. The storage device 818 may include a storage device such as, for example, a magnetic disk, an optical disk (eg, CD-ROM, DVD player), a random access memory (RAM) disk, a tape device, and / or a flash drive. The information may be stored on one or more non-transitory tangible computer readable media contained within the storage device. The medium may include, for example, a magnetic disk, optical disk, magnetic tape, and / or memory device (eg, a flash memory device, a static RAM (SRAM) device, a dynamic RAM (DRAM) device, or other memory device). Information may include data and / or computer-executable instructions that may implement one or more embodiments of the invention.

  Storage device 818 may store any modules, outputs, displays, files 820, information, user interfaces, etc. provided in the example embodiments. Storage device 818 may store an application 822 for use by computing device 800 or another electronic device. Application 822 may include programs, modules, or software components that allow computing device 1300 to perform tasks. Examples of applications include document processing software, shells, internet browsers, productivity suites, and programming software. Storage device 818 may store not only data for use by computing device 800 or another device, but also additional applications for providing additional functionality. Data may include files, variables, parameters, images, text, and other types of data.

  Storage device 818 may further store an operating system (OS) 824 for executing computing device 800. Examples of OS 824 include embedded operating systems such as Microsoft® Windows® operating system, Unix® and Linux® operating systems, MacOS® for Macintosh computers, and Symbian OS. May include a system, a real-time operating system, an open source operating system, a proprietary operating system, an operating system for portable electronic devices, or other operating system capable of executing on an electronic device to perform the operations described herein . The operating system may be run in native mode or emulated mode.

  In one embodiment, computing device 800 may include a feature-based modeling environment 830 for building a model. The modeling environment 830 can be, for example, a software component or a computer program. The modeling environment 830 can be a CAD environment. The modeling environment 830 may include means for building, editing, saving and loading the model 110, simulating the performance of the model 110, and providing the model 110 as input to a rapid prototyping or manufacturing unit. The modeling environment 830 can further include a geometry kernel 832, which can compute and represent the shape of features in the model.

  One or more embodiments of the invention may be implemented using computer-executable instructions and / or data, which may be embodied on one or more non-transitory tangible computer-readable media. Media include hard disk, compact disk, digital versatile disk, flash memory card, programmable read only memory (PROM), random access memory (RAM), read only memory (ROM), magnetoresistive random access memory (MRAM), magnetic tape , Or other computer readable medium, but is not limited thereto.

  One or more embodiments of the invention may be implemented in a programming language. Some examples of languages that can be used include Python, C, C ++, C #, SystemC, Java, Javascript, Hardware Description Language (HDL), Unified Modeling Language (UML), and Programmable Logic Control Including but not limited to device (PLC) language. Further, one or more embodiments of the present invention may be implemented in a hardware description language or other languages that allow calculation instructions. One or more embodiments of the invention may be stored as object code on or in one or more media. Instructions that may implement one or more embodiments of the invention may be executed by one or more processors. Part of the present invention may be in instructions that execute with respect to one or more hardware components other than a processor.

  It should be understood that the present invention may be implemented in a distributed or network environment. For example, a model can be provided and operated at a central server, while a user interacts with the model through a user terminal.

  FIG. 9 illustrates a network implementation in which one or more embodiments of the present invention may be implemented. System 900 may include computing device 800, network 910, service provider 920, modeling environment 830, and cluster 930. The embodiment of FIG. 9 is exemplary, and other embodiments may include more devices, fewer devices, or a different arrangement of devices than the arrangement of FIG.

  Network 910 may transmit data from a source to a destination. Embodiments of network 910 may use network devices such as routers, switches, firewalls, and / or servers (not shown), and connections (eg, links) for transmitting data. The data can be of any type having virtually any format that can be adapted for use with one or more networks and / or one or more devices (eg, computing device 800, service provider 920, etc.). Can refer to machine-readable information. The data can include digital information or analog information. The data may be further packetized and / or not packetized.

  Network 910 may be a wired network using wired conductors and / or optical fibers and / or may be a wireless network using free space light, radio frequency (RF), and / or acoustic transmission paths. . In one implementation, network 910 may be a substantially open public line, such as the Internet. In another implementation, the network 910 may be a more restricted network, such as a corporate virtual network. Network 910 may include the Internet, an intranet, a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a wireless network (eg, using IEEE 802.11), or other types of networks. . Network 910 may use middleware, such as Common Object Request Broker Architecture (CORBA) or Distributed Component Object Model (DCOM). Implementations of the networks and / or devices operating on the networks described herein are not limited to any particular data type, protocol, and / or architecture / configuration, for example.

  Service provider 920 may include a device that makes the service available to another device. For example, service provider 920 may include entities (eg, individuals, businesses, educational institutions, government agencies, etc.) that use a server and / or other devices to provide one or more services to a destination. A service may include instructions executed by a destination to perform an operation (eg, an optimization operation). Alternatively, the service may include instructions that are executed on behalf of the destination to perform operations on behalf of the destination.

  Modeling environment 830 may include devices that receive information via network 910. For example, the modeling environment 830 can be hosted on a device that receives user input from the electronic device 800.

  Cluster 930 may include a number of execution units (EU) 932 and may perform processing on behalf of another device, such as electronic device 800 and / or service provider 920. For example, the cluster 930 may perform parallel processing for operations received from the electronic device 800. Cluster 930 may include EU 932 resident on a single device or chip, or resident on several devices or chips.

  EU 930 may include a processing device that performs operations on behalf of a device, such as a requesting device. The EU may be a microprocessor, a field programmable gate array (FPGA), and / or another type of processing device. EU 932 may include code, such as code for an operating environment. For example, the EU may execute a portion of the operating environment associated with parallel processing operations. Service provider 920 may operate cluster 930 and provide interactive optimization functionality to electronic device 800 on a subscription basis (eg, via a web service).

  The EU may provide remote / distributed processing capabilities for products such as the modeling environment 830 of FIG. A hardware EU may include devices (eg, hardware resources) that may perform parallel programming operations and / or participate in parallel programming operations. For example, a hardware EU may perform parallel programming operations and / or in parallel programming operations in response to requests and / or tasks that it is receiving (eg, received directly or via a proxy). Can be involved. A hardware EU may use and / or participate in substantially any type of parallel programming (eg, tasks, data, stream processing, etc.) using one or more devices. For example, a hardware EU may include a single processing unit that includes multiple cores or several processors. The hardware EU may also be a programmable device such as a field programmable gate array (FPGA), application specific integrated circuit (ASIC), digital signal processor (DSP), or other programmable device. The devices used within the hardware EU may be arranged in a number of different configurations (or topologies), such as a grid, ring, star, or other configuration. A hardware EU may support one or more threads (or processes) when performing processing operations.

  A software EU may include software resources (eg, a technical computing environment) that may perform one or more parallel programming operations and / or participate in the parallel programming operations. The software EU may perform and / or participate in one or more parallel programming operations in response to receiving the program and / or one or more portions of the program. A software EU may use and / or participate in different types of parallel programming using one or more hardware execution units. A software EU may support one or more threads and / or processes when performing processing operations.

  The term “parallel programming” may be understood to include multiple types of parallel programming, eg, task parallel programming, data parallel programming, and stream parallel programming. Parallel programming can include various types of processing that can be distributed across multiple resources (eg, software execution units, hardware execution units, processors, microprocessors, clusters, labs) and executed simultaneously.

  For example, parallel programming can include task parallel programming, where several tasks can be processed simultaneously on several software execution units. In task parallel programming, tasks can be processed simultaneously, for example, independently of other task executions.

  Parallel programming can include data parallel programming, in which case the data (eg, a data set) can be decomposed into several parts that can be executed in parallel, eg, using a software execution unit. In data parallel programming, software execution units and / or data portions may communicate with each other as processing proceeds.

  Parallel programming can include stream parallel programming (sometimes referred to as pipeline parallel programming). Stream parallel programming may use several software execution units, for example arranged in series (eg straight lines), in which case the first software execution unit may be fed to the second software execution unit. One result may be generated, and the second software execution unit may produce a second result given the first result. Stream parallel programming can also include situations in which task assignments can be expressed in a directed acyclic graph (DAG) or a cyclic graph.

  Other parallel programming techniques may include any combination of task, data, and / or stream parallel programming techniques only, or other types of processing techniques to form a hybrid parallel programming technique.

  The foregoing description may provide examples and descriptions of various embodiments of the invention, but is not intended to be exhaustive or to limit the invention to the precise forms disclosed. Modifications and variations may be possible in light of the above teachings or may be derived from practice of the invention. For example, although a series of operations has been described above, the order of operations can be altered in other embodiments consistent with the principles of the invention. Furthermore, independent operations can be performed in parallel. Further, although features and access classes have been described above using a particular syntax, features and access classes can be similarly specified using different methods and using different syntax.

  In addition, one or more embodiments consistent with the principles of the present invention may be illustrated in the drawings without departing from the spirit of the present invention, and one or more devices and / or other than those described herein. Or it can be implemented using a configuration. One or more devices and / or components may be added to and / or removed from the drawing embodiments, depending on the particular arrangement and / or application. Moreover, one or more disclosed embodiments are not limited to a particular combination of hardware.

  Moreover, certain portions of the invention can be implemented as logic that can be performed by one or more functions. This logic may include hardware such as wired logic, application specific integrated circuits, field programmable gate arrays, microprocessors, software, or a combination of hardware and software.

  Any element, operation, or instruction used in the description of the specification should not be construed as important or essential to the invention unless explicitly described as such. Also, as used herein, the article “one (a)” is intended to include one or more items. Where only one item is intended, the term “single” or similar term is used. Further, the phrase “based on” is intended herein to mean “based at least in part” unless specifically stated otherwise. In addition, the term “user” is intended herein to be broadly interpreted to include, for example, an electronic device (eg, a workstation) or an electronic device user, unless otherwise specified.

  The present invention is not limited to the specific embodiments disclosed above, but the present invention is intended to include any and all specific embodiments and equivalents included within the scope of the following appended claims.

Claims (19)

A non-transitory computer usable 読媒 body for storing instructions, the instructions, when executed by a processor, the processor,
Receiving a request to create a checkpoint for a model during an edit session of the model by a party;
Identifying a previously saved state of the model;
Identifying one or more components that have changed in the model since the previously saved state of the model;
In response to the request, creating a checkpoint during the editing session, the checkpoint representing a current state of the model, and a previous checkpoint of the editing session by the party A reference to the previously saved state of the model associated with
A list of one or more components modified in the model during the editing session since the previously saved state of the model; and
Storing the checkpoint in a storage device;
Reverting to the checkpoint during the editing session of the model by the party, the reverting the model to the saved state associated with the checkpoint of the editing session by the party. return, and that,
Entering the design session,
Identifying a basic model to be used as an unchanged model for the design session;
Creating an entry checkpoint consisting of the basic model ; and
A medium in which the checkpoint is represented as a tree structure and the entry checkpoint represents the root of the tree structure . The basic model and the checkpoint further storing instructions to be stored in the design session file on the first computer, the medium of claim 1. Opening the design session file on a second computer;
Creating a model on the second computer that matches the checkpoint;
The medium of claim 2 , further comprising instructions for performing. A non-transitory computer readable medium storing instructions, wherein when executed by a processor, the instructions are
Receiving a request to create a checkpoint for a model during an edit session of the model by a party;
Identifying a previously saved state of the model;
Identifying one or more components that have changed in the model since the previously saved state of the model;
In response to the request, creating a checkpoint during the editing session, wherein the checkpoint represents a current state of the model; and
A reference to the previously saved state of the model associated with a previous checkpoint of the editing session by the party;
A list of the one or more components modified in the model during the editing session since the previously saved state of the model;
Including, and
Storing the checkpoint in a storage device;
Reverting to the checkpoint during the editing session of the model by the party, the reverting the model to the saved state associated with the checkpoint of the editing session by the party. To return
Receiving an instruction to modify a first component of the model;
Modifying the model based on the instructions to provide an explicit change to the model;
Identifying a derivative change to a second component of the model, wherein the derivative change results from the explicit change, and in a user instruction to modify the second component Not caused,
Storing references to the first component and the second component in the list of the one or more components that have changed in the model since the previously saved state of the model;
The medium that causes The medium of claim 4 , wherein the derivative change is based on a parametric relationship between the first component and the second component. A non-transitory computer readable medium storing instructions, wherein when executed by a processor, the instructions are
Receiving a request to create a checkpoint for a model during an edit session of the model by a party;
Identifying a previously saved state of the model;
Identifying one or more components that have changed in the model since the previously saved state of the model;
In response to the request, creating a checkpoint during the editing session, wherein the checkpoint represents a current state of the model; and
A reference to the previously saved state of the model associated with a previous checkpoint of the editing session by the party;
A list of the one or more components modified in the model during the editing session since the previously saved state of the model;
Including, and
Storing the checkpoint in a storage device;
Reverting to the checkpoint during the editing session of the model by the party, the reverting the model to the saved state associated with the checkpoint of the editing session by the party. To return
And execute
The reference to the state saved the prior of the model contains a pointer to the second checkpoint, medium. A method,
Receiving a request in a computing device to return a model to a saved state stored in a storage device, wherein the model includes a component;
Obtaining a checkpoint associated with the saved state at a processor of the computing device, the checkpoint being changed to a reference to a previous checkpoint and after the previous checkpoint; Including a list of modified components in the model; and
Processing the previous checkpoint in the processor to compare the previous checkpoint with the current state of the model, the processing comprising: changing the component of the model to the changed component; Including identifying what is in the list, and
Changing the component in the model based on the list of changed components at the processor to return the model to the saved state. Returning the model to the saved state replaces only the components of the model that have changed since the previous checkpoint, while any of the models that have not been changed since the previous checkpoint. The method of claim 7 , comprising maintaining the component. The method of claim 7 , wherein the previous checkpoint is an entry checkpoint associated with a base model, and the base model is used as the previous version of the model. Processing the previous checkpoint includes: a second previous checkpoint; and a list of components modified in the model between the previous checkpoint and the second previous checkpoint. The method of claim 7 , comprising obtaining. Returning the model to the stored state;
Getting the basic model associated with the entry checkpoint;
Obtaining a series of one or more checkpoints between the entry checkpoint and the checkpoint associated with the saved state, wherein the series of checkpoints has been modified by one or more Including a collection of components,
Identifying a component in the model corresponding to the changed component;
8. The method of claim 7 , comprising replacing the identified component with the modified component with respect to the base model. The list of modified components is
A first component modified by an explicit change made to the model by an explicit instruction to change the model;
To satisfy one or more parameters constraints on the model, and a second component modified by the consequential changes made to the model as a result of the explicit changes, to claim 7 The method described. A system,
A non-transitory computer readable storage medium storing a model in a first state, wherein the model in the first state includes a first component;
With processor
With
The processor is
The method comprising: tracking the one or more changes made to the model of the first state, to track the one or more changes,
Identifying an instruction that causes the first component to cause an explicit change;
Recording the explicit change in a list of changes;
The related components associated with the first component, based on the consequential changes to the explicit prior Symbol related components arising by a change, and identifying
Including, and
Receiving a request to create a checkpoint for the model during an editing session of the model by a party ;
In response to the request, creating the checkpoint representing the current state of the model during the editing session, the checkpoint comprising :
Reference and to a previously saved state of the model associated with and earlier checkpoint of the editing session by the party,
The includes a first component, and a list of changed components including said related components that have been modified in said model in said editing session the previously saved state after the model, and that,
Storing the checkpoint in the non-transitory computer readable storage medium ;
A by returning to the check point in the editing session of the model by the party, said return it, the model, the stored associated with the following prior to checkpoint the editing session by the party To return to the state ,
Entering the design session,
Identifying a basic model to be used as an unchanged model for the design session;
Creating an entry checkpoint consisting of said basic model ,
The system wherein the checkpoint is represented as a tree structure and the entry checkpoint represents the root of the tree structure . The system of claim 13 , wherein identifying the relevant component comprises examining a parameter constraint associated with the model. The system of claim 13 , wherein tracking the one or more changes comprises storing an identification of the associated component along with the list of changed components. The system of claim 13 , wherein the first component is stored with the list of related components. The system of claim 13 , wherein identifying the related component comprises analyzing the first component for connections to other features.   A system,
  A non-transitory computer readable storage medium storing a model in a first state, wherein the model in the first state includes a first component;
  With processor
With
  The processor is
  Tracking one or more changes made to the model in a first state, tracking the one or more changes;
    Receiving an instruction to modify the first component of the model;
    Modifying the model based on the instructions to provide an explicit change to the model;
    Identifying a derivative change to a second component of the model, wherein the derivative change results from the explicit change, and in a user instruction to modify the second component Not caused, and
  Including, and
  Receiving a request to create a checkpoint for the model during an editing session of the model by a party;
  In response to the request, creating the checkpoint representing the current state of the model during the editing session, the checkpoint comprising:
    A reference to a previously saved state of the model associated with a previous checkpoint of the editing session by the party;
    A modified component comprising a reference to the first component and a reference to the second component that has been modified in the model during the editing session since the previously saved state of the model. List and
  Including, and
  Storing the checkpoint in the non-transitory computer readable storage medium;
  Reverting to the checkpoint during the editing session of the model by the party, wherein the reverting causes the model to be associated with a previous checkpoint of the editing session by the party. To return to
A system that is programmed to run   A system,
  A non-transitory computer readable storage medium storing a model in a first state, wherein the model in the first state includes a first component;
  With processor
With
  The processor is
  Tracking one or more changes made to the model in a first state, tracking the one or more changes;
    Identifying an instruction that causes the first component to cause an explicit change;
    Recording the explicit change in a list of changes;
    Identifying a related component associated with the first component based on a derivative change to the related component caused by the explicit change;
  Including, and
  Receiving a request to create a checkpoint for the model during an editing session of the model by a party;
  In response to the request, creating the checkpoint representing the current state of the model during the editing session, the checkpoint comprising:
    A reference to a previously saved state of the model associated with a previous checkpoint of the editing session by the party;
    A list of modified components including the first component and the related components modified in the model during the editing session since the previously saved state of the model;
  Including, and
  Storing the checkpoint in the non-transitory computer readable storage medium;
  Reverting to the checkpoint during the editing session of the model by the party, wherein the reverting causes the model to be associated with a previous checkpoint of the editing session by the party. To return to
  Is programmed to run
  The system, wherein the reference to the previously saved state of the model includes a pointer to a second checkpoint.

Images