Ordering optional constraints in a variational system

Methods for product data management and corresponding systems and computer-readable mediums. A method includes receiving a CAD model in the data processing system, the CAD model a plurality of features and constraints, including optional constraints. The method includes receiving a user operation to manipulate a seed feature, and identifying a plurality of optional constraints corresponding to the user operation. The method includes sorting the optional constraints and applying a sorted optional constraint. The method includes performing the user operation according to the applied constraints to produce a modified CAD model and storing the modified CAD model.

TECHNICAL FIELD

The present disclosure is directed, in general, to computer-aided design, visualization, and manufacturing systems, product lifecycle management (“PLM”) systems, and similar systems, that manage data for products and other items (collectively, “Product Data Management” systems or “PDM” systems).

BACKGROUND OF THE DISCLOSURE

PDM systems manage PLM and other data. Improved systems are desirable.

SUMMARY OF THE DISCLOSURE

Various disclosed embodiments include methods for product data management, corresponding systems, and computer-readable mediums. A method includes receiving a CAD model in the data processing system, the CAD model a plurality of features and constraints, including optional constraints. The method includes receiving a user operation to manipulate a seed feature, and identifying a plurality of optional constraints corresponding to the user operation. The method includes sorting the optional constraints and applying a sorted optional constraint. The method includes performing the user operation according to the applied constraints to produce a modified CAD model and storing the modified CAD model.

DETAILED DESCRIPTION

Within a variational modeling system, such as the “Synchronous Technology” processes used in Siemens Product Lifecycle Management Software, Inc. products, changes are generally expressed variationally. A variational system describes the parameters of and relationships between features in an object model in terms of geometric constraints and dimensions. Such systems then use a “solver” process to process these constraints and dimensions, along with a multitude of ancillary constraints and dimensions required to maintain design intent, and the entire model is solved simultaneously.

In such a variational modeling system, achieving “natural” behavior is a key goal. In realistic complex models an edit can expect to encounter a combination of aspects, each of which has a corresponding “natural” behavior. It is only when a system can consistently define overall behavior in such combination cases, often requiring conflict resolution, that it can be truly useful.

Disclosed embodiments include a definition of combined behavior and systems and methods for achieving it.

FIG. 1depicts a block diagram of a data processing system in which an embodiment can be implemented, for example, as a PDM system particularly configured by software or otherwise to perform the processes as described herein, and in particular as each one of a plurality of interconnected and communicating systems as described herein. The data processing system depicted includes a processor102connected to a level two cache/bridge104, which is connected in turn to a local system bus106. Local system bus106may be, for example, a peripheral component interconnect (PCI) architecture bus. Also connected to local system bus in the depicted example are a main memory108and a graphics adapter110. The graphics adapter110may be connected to display111.

Other peripherals, such as local area network (LAN)/Wide Area Network/Wireless (e.g. WiFi) adapter112, may also be connected to local system bus106.

Expansion bus interface114connects local system bus106to input/output (I/O) bus116. I/O bus116is connected to keyboard/mouse adapter118, disk controller120, and I/O adapter122. Disk controller120can be connected to a storage126, which can be any suitable machine usable or machine readable storage medium, including but not limited to nonvolatile, hard-coded type mediums such as read only memories (ROMs) or erasable, electrically programmable read only memories (EEPROMs), magnetic tape storage, and user-recordable type mediums such as floppy disks, hard disk drives and compact disk read only memories (CD-ROMs) or digital versatile disks (DVDs), and other known optical, electrical, or magnetic storage devices.

Also connected to I/O bus116in the example shown is audio adapter124, to which speakers (not shown) may be connected for playing sounds. Keyboard/mouse adapter118provides a connection for a pointing device (not shown), such as a mouse, trackball, trackpointer, etc.

Those of ordinary skill in the art will appreciate that the hardware depicted inFIG. 1may vary for particular implementations. For example, other peripheral devices, such as an optical disk drive and the like, also may be used in addition or in place of the hardware depicted. The depicted example is provided for the purpose of explanation only and is not meant to imply architectural limitations with respect to the present disclosure.

LAN/WAN/Wireless adapter112can be connected to a network130(not a part of data processing system100), which can be any public or private data processing system network or combination of networks, as known to those of skill in the art, including the Internet. Data processing system100can communicate over network130with server system140, which is also not part of data processing system100, but can be implemented, for example, as a separate data processing system100.

Optional constraints are those that are applied to the model only if they do not prevent a given edit from occurring. They are different from regular constraints which may prevent a model from being edited.

FIGS. 2A and 2Billustrate required and optional constraints, in accordance with disclosed embodiments.FIG. 2Ashows a simple model of two lines202and204that are constrained to be a specified distance apart. In this case, line202is also constrained to be fixed in location.

If the system or user attempts to move line204to the right, as illustrated, the move edit would fail in a conventional constraint system. This is due to the rigid distance constraint between the line204being moved and line202.

However, if the distance constraint is converted to an optional constraint, a “distance-if-possible,” the edit can now succeed, but with the distance being broken.FIG. 2Billustrates the result, with the move successful but the optional distance constraint now unsatisfied. The same principals apply to simple or complex two-dimensional (2D) or three-dimensional (3D) models.

Optional constraints are useful in controlling the general behavior of model edits. Behavior could be controlled by adding regular constraints to the system, but very often these additional constraints would conflict with the other constraints on the model, placed either by the system or by the user, or would conflict directly with the edit being attempted. Using optional constraints to control behavior means there are no conflicts.

There are many examples where describing general behavior in terms of optional constraints is useful, such as avoiding cylinders changing their radius and avoiding planes from rotating.

When using optional constraints to control behavior, most model edits will result in multiple optional constraints being generated. Within these optional constraints it is possible that some will conflict, giving a choice over which is applied, i.e., it is possible to apply optional constraint A or B, but not both A and B.

If a system is trying to automatically give intuitive behavior to the user, then any optional constraints in the system must be ordered by some methodology so that the most important optional constraints are applied in preference to less important optional constraints.

Disclosed embodiments include systems and methods that apply optional constraints in a manner that produces a more interactive interaction and intuitive response to a user.

Disclosed embodiments apply a set of ordering requirements to order a given set of optional constraintsThe order should be unique for a given edit on a given model;The order should take into account a number of general behavioral preferences, such as “preventing geometries from rotating” being more important than “preventing geometries from changing size”;The order should be dependent on the edit that is being requested by the user, meaning that the order will change for different edits on the same model;The order should be dependent on the model presented to the system, meaning that adding additional constraints to a system should change the order of any optional constraints;The order of lower priority constraints should be able to change as higher priority constraints are imposed; andAny process should be easily expandable to handle special cases.

To meet these requirements, disclosed embodiments use a sorting process that orders a given set of optional constraints on a given model for a given edit based on the following properties, each described in more detail below:By behavior class;By information known about the feature being constrained;By distance from the edit; andBy static model properties.

Specific embodiments can order constraints in the general order listed above, but this ordering is not strictly necessary in all embodiments. For example, particular elements of the behavior class, known information, and distance may be mixed to give more intuitive behavior.

Behavior class: “Behavior class” is defined to be the reason a particular optional constraint (or constraints) was created. There are many reasons why an optional constraint may be created, but these generally fall into two broad categories. First, those based on information the user has given, such as dimensions that have been placed on the model. Second, those based on certain geometric configurations of elements in the model, in its un-edited state.

One example of a behavior class is dimension-end data, where the faces on which a dimension acts are given certain behavior. Another example of a behavior class is ortho-locking, where geometries are measured to be aligned to the principle axes of the part and requested to keep this alignment. Another example of a behavior class is size locking, where geometries are defined to have certain size properties and are requested to keep this size. Another example of a behavior class is pattern spacing, where a pattern is defined to have certain spacing properties which are requested to be kept. Another example of a behavior class is tipping, where geometries are adjacent to each other and must rotate to stay adjacent as the model is changed. Of course, these examples are not intended to be exhaustive or limiting.

The system can prioritize a given set of behavior classes with respect to each other to give a general optional constraint order. This prioritization could be static, automatically adjusted for certain types of part, or controlled by the user via options if necessary.

Information known about the feature: Some optional constraints may be added to the system to ensure some general behavior of a particular feature. For example, for a feature with a local coordinate system defining local-X and local-Z directions, the system or user can define desirable behavior properties.

One example of a desirable behavior property based on known information is that it is preferable for a feature to move rather than rotate, implying a local order of any optional constraints added to the system, e.g., local-X constraints before local-Z constraints.

Another example of a desirable behavior property based on known information is that, if a feature has to move, then don't constrain it to move in a particular direction. This implies that any secondary optional constraints should not be applied if the first cannot be applied.

To enable local ordering, clusters of optional constraints are defined by the feature, where the order of the constraints within the cluster is used to define the order and adjacency of the constraints in the main sorted list.

Distance from the edit: To describe “distance from the edit”, the following terms are used herein. “Operation” refers to the edit the user is making on the model. “Seeds” or “seed features” refers to the geometries the user is acting directly on to make the edit. “Objects” refers to the features of the model that cause constraints to be generated and solved and as a result link geometries together.

“Distance from the edit” refers to the shortest distance between a geometry with an optional constraint applied to it and the “seeds” of the operation, when measured with respect to objects in the model.

The distance is computed by building a graph representing the geometries involved in the edit (the nodes), linked together by objects (the edges). The shortest distance between any two geometries (or nodes) can then be measured by following a series of edges through the graph using standard graph analysis techniques.

Examples of the objects represented in the graph are dimensions, such as distance or angle; constraints, such as concentric or parallel; and features, such as holes or patterns.

The distance measured must take into account any geometries (or nodes) that are fixed. To give intuitive behavior, the shortest distance should not pass through geometries that are known to be fixed.

In addition, as optional constraints are added to the model, a geometry that was previously able to move may now become fixed. Therefore, the system re-evaluates the freedoms of all geometries in the model and updates distances within the graph accordingly before sorting any remaining optional constraints.

Static model properties: To arrive at a final definite ordering for all optional constraints, the system can use some static model properties. These properties are used to ensure the ordering is definite and therefore repeatable, rather than only to affect behavior. Examples of static properties of the model that can be used include the position of geometries, for example geometries could be ordered by their X, Y, and Z position in 3D space, and identifiers associated with geometries can then be used to identify them in the system.

FIG. 3depicts a process in accordance with disclosed embodiments, that can be performed, for example, by one or more PDM data processing systems such as data processing system100, referred to generically below as the “system”.

The system receives a CAD model (step305). This can be a 2D or 3D model, and the model includes a plurality of features and constraints, including optional constraints.

The system receives a user operation (step310). The user operation is an edit the user is making to the model by manipulating at least one seed feature.

The system identifies a plurality of optional constraints corresponding to the user operation (step315)

The system sorts the optional constraints (step320). The sorting can be according to any or all of the properties described above, including by behavior class, by information known about each feature being constrained, by distance from the edit (seed feature), or by static model properties.

The system can also define a dependency between optional constraints where secondary constraints will only be applied if the first constraint is applied. In other cases, this dependency can be based on any criteria or special case in the model. This dependency can be considered as part of the sorting process.

The system applies the first sorted optional constraint (step325).

The system removes the applied optional constraint from the identified optional constraints (step330).

The system repeats steps320,325, and330until there are no remaining identified constraints that have not been applied. The process of applying the first sorted constraint, then resorting the remaining constraints before they are applied allows the application of constraints higher in the list to affect the order of constraints lower in the list. This provides a distinct technical advantage in enabling the edit process to adapt to changes in the freedoms of geometries.

A general ability to drop optional constraints based on certain criteria or dependencies is facilitated by the above general process whereby all subsequent constraints are re-sorted as more important ones are applied.

The system performs the operation according to the applied constraints (step335) to produce a modified CAD model.

The system stores the modified CAD model (step340), and can also display the modified CAD model.

Of course, those of skill in the art will recognize that, unless specifically indicated or required by the sequence of operations, certain steps in the processes described above may be omitted, performed concurrently or sequentially, or performed in a different order. Any of the other features and processes described above can be included in the process ofFIG. 3.

FIGS. 4A-4Fillustrate an example of general optional constraint ordering in accordance with disclosed embodiments.

FIG. 4Ashows a simple 2D model400. In this example, the circle402is being moved to the left, as indicated by arrow420. It is concentric with the outer arc404, which is tangent to the adjacent vertical line406and horizontal line408. The vertical line is tangent to the top arc410, and the top arc is concentric to the top circle412.

FIG. 4Billustrates two possible results of moving circle402while maintaining these constraints. Both are reasonable, but the left result is probably more desirable because it preserves the vertical alignment of the vertical line.

FIG. 4Cillustrates a similar 2D model430. In this example, the circle432is being moved to the left, as indicated by arrow450. It is concentric with the outer arc434, which is tangent to the adjacent angled line436and horizontal line438. The angled line is tangent to the top arc440, and the top arc is concentric to the top circle442.

In this case, the result shown inFIG. 4Dis more reasonable because more rotation is being applied to an already rotated line.

The decision process for achieving this behavior can be generalized by placing a set of optional constraints and then ordering them correctly.

FIG. 4Eillustrates the model400ofFIG. 4Awith optional constraints. In this case, the labeled constraints are:

DNM=Do Not Move (if possible), created for “tipping”.

FIG. 4Fillustrates the model430ofFIG. 4Cwith optional constraints. Note the decision to not place a DNR on line 2 is based on its original orientation:

The system or user can order the optional constraints by the following logic to get the correct behavior:Order first by reason the optional constraint was created, ortho-locking or tipping in the above examples, with ortho-locking considered more important than tipping.Order second by constraint distance from the target of the operation (circles402and432), furthest away first.Order third by static model properties, such as IDs.Drop some optional constraints based on special conditions.

This logic produces the following order for the example of model400:

This results in the following processing according to the process described above. The constraints are ordered first by type, then by distance from the edit. “DNR—line 2” and “DNR—line 3” are still equal so are ordered by model property, for example the number of the geometry. “DNM—line 2” and “DNM line 3” are also equal, but a special case for tipping rules that are equal distance is established where both rules are dropped so as not to force undesirable behavior.

This logic produces the following order for the example of model430:

In this case, “DNM—arc 1” is additionally applied, thus forcing the rotation behavior of line 2.

FIGS. 5A-5Dillustrate an example of optional constraint ordering including measuring the distance from an edit, in accordance with disclosed embodiments.

FIG. 5Ashows a simple 2D model500to illustrate an example of distance. The five faces in this example below, faces a to e, are related by model data in such a way that there is one graph step between each adjacent face.

In an example operation, face a502is the seed, and is being translated in the direction shown by arrow520, and its length is constrained to remain unchanged. The distances of faces a to e are shown as the circled numbers inFIG. 5A: 0 for the seed, to 4 for face e, which is the most distant as measured by graph connectivity.

As an example of behavior, the system attempts to apply optional constraints to not move faces a to e. The optional constraints would be ordered furthest away from the edit as follows:

FIG. 5Billustrates the resulting change to model500using this order. Note that faces a is moved (the move made by the user), and face b was moved (as it must to remain connected to face a), but faces c-e are not moved.

For the same operation, if the model data is changed adding additional non-optional constraints between face a and face e such that the two faces must translate rigidly, and neither may change length, then the graph connectivity will be significantly altered. The inclusion of the constraint between faces a and e in the operation brings face d nearer to the operation being performed.FIG. 5Cillustrates a model530, similar to model500, but with these additional constraints. The user wishes to move face a532in the direction of arrow550.

The same optional constraints would be generated, however they would now be ordered as follows:

FIG. 5Dillustrates the resulting change to model530using this order of optional constraints, and maintaining the non-optional constraints.

FIGS. 6A-6Cillustrate an example of optional constraint ordering including using feature information present in the model, in accordance with disclosed embodiments.

The preferred behavior of dependent features can also be defined using ordered optional constraints.

FIG. 6Ashows an example of a 3D model600in which a feature A (cube602) is placed on feature B (cuboid604).

Under edit, the following behaviors are desirable:If feature B (cuboid604) moves, feature A (cube602) should also move; andIf feature A (cube602) moves, feature B (cuboid604) should not move.

This can be achieved by the following local ordering of optional constraints, defined by the dependency between the features:DNM on feature B (cuboid604);DNM on feature A (cube602); andKeep-rigid between A (cube602) and B (cuboid604) applied only if B is moving.

Using this order when feature B is moved produces:DNM on feature B (cuboid604)—Not applied;DNM on feature A (cube602)—Not applied; andKeep-rigid between A (cube602) and B (cuboid604) applied only if B is moving—Applied.

FIG. 6Billustrates the result of moving feature B (cuboid604).

Using this order when feature A is moved produces:DNM on feature B—Applied;DNM on feature A—Not applied; andKeep-rigid between A and B applied only if B is moving—Not Applied

FIG. 6Cillustrates the result of moving feature A (cuboid602).

If further dependent features are ‘stacked’, then this process extends naturally to support the correct behavior.

Disclosed embodiments enable a user to perform accurate and intuitive editing of CAD models taking into account combined behavior. The processes described herein can implement a defined ordering of individual “natural” behaviors, when encountered in combination, based on considerations including behavior type, distance from the point of action, and other specific model and domain properties. Use of optional constraints as described herein can manage the following examples of individual behavior to produce an overarching natural behavior of the system as a whole:When moving a geometric feature such as a hole, boss, etc., the edit should not drive the geometry it is constructed upon (i.e., its under);When changing or moving a geometry, any geometric features constructed upon it such as holes, bosses, etc., should move with it in sympathy with the input change applied;Specifically, in the sheet metal context, moving a “thickness face” should not drive the owning plate to move;When changing the value of a dimension (distance or angle) which drives a vertex, then the faces incident at that vertex should change minimally, preferably with most remaining fixed and only one moving;When a cone geometry is present in the model, and particularly when the cone is tangent to another geometry, then the cone should be preferentially prevented from sliding along its axis;Geometry which is initially aligned to the principle directions of the model should preferentially remain so;Internal freedoms such as radii, half angle, etc., should preferentially remain unchanged;The spacing between occurrences of a pattern should preferentially remain unchanged; andThe quantity of neighboring faces included in a change should be minimized by allowing faces to “tip” as a way of bounding the changeset.

Various disclosed embodiments include using a process as described above to encode the individual behaviors using optional constraints, and using a process as described above to encode the combined behavior above using ordering of optional constraints based on the types of behavior, the distance from the point of action, and specific properties of the model.