Overview

of Rules and Constraints

You can use rules and constraints in the design applications to control certain actions. The generative flow (and wiring synthesis in particular) rely on user-configured constraints to control the results of the automated process.

This overview examines the following concepts:

• Constraints

• Rules

• Object Rule Hierarchies in Capital Systems Integrator

When starting to work with this toolset, it is recommended that you create an organized strategy for using constraints. See Creating a Strategy for Constraint Definition in Capital Systems Integrator.

Constraints

A constraint is a statement that you can apply to a whole design, or to individual objects within a design. You can apply it as an individual constraint or as part of a rule.

For example (in Capital Systems Integrator):

Don't place devices with property matching Name=Battery here.

If this example constraint were set for a slot, the system would not place a device with a Name property of Battery in that slot.

You use constraint templates in Capital Systems Integrator to define a constraint.

The templates listed below in this topic are standard in Capital Systems Integrator. You can write your own custom constraints in Java and load them into Capital Systems Integrator. For more information about writing and loading custom constraints, see the PluginDevelopment.pdf document that is located in the doc\plugin folder of your Capital installation. Once custom constraints are loaded into Capital Systems Integrator, you use them in the same way as standard constraints. An object can have both standard and custom constraints defined for it.

The design rule check Missing Custom Constraint Check can be run to report on any custom constraints that exist for an object but are not loaded any longer in Capital Systems Integrator. See Running Design Rule Checks Manually for more information about running design rule checks.

For further details about constraints, see Creating a Strategy for Constraint Definition in Capital Systems Integrator and Assigning a Rule or Constraint to an Object in the Capital Design Tools - Common Functions User Guide.

Rules

A rule is a group of constraints that you can apply to a whole design or to individual objects in a diagram. You can define rules from within Capital Systems Integrator or from within Capital Project Manager. In Capital Project Manager, you can define rules either at a project level or you can define rule libraries at a system level. You can add a rule library to a project. See the Capital Project Manager help system for more information about defining rule libraries.

For further details about rules, see Defining Rules in the Capital Design Tools - Common Functions User Guideor Assigning a Rule or Constraint to an Object in the Capital Design Tools - Common Functions User Guide.

Object Rule Hierarchies in Capital Systems Integrator

You can set rules and constraints for different objects in a design and this means that there can be conflicts between the rules and constraints that exist. For this reason, there are the following general hierarchies that determine which constraint is used on each object:

• Bundle hierarchy A constraint on a bundle overrides a constraint on a harness. A constraint on a harness overrides a constraint on a design.

• Slot hierarchy A constraint on a slot overrides a constraint on a design.

• Cavity hierarchies A constraint on a cavity overrides a constraint on a slot connector. A constraint on a slot connector overrides a constraint on a slot. A constraint on a slot overrides a constraint on a design.

• Inline cavity hierarchy A constraint on an inline cavity overrides a constraint on an inline connector. A constraint on an inline connector overrides a constraint on a design. An inline connector inherits rules and constraints from the design but does not inherit constraints from any connected harnesses. Caution Constraints of the same type (that is, they potentially conflict) use the rule resolver mechanisms described below. Constraints of different types (that is, they do not directly conflict) are not evaluated in any particular sequence. This is not usually a problem because most constraints are evaluated at different times anyway. However, there can be an issue if you have different but related constraints. For example, one constraint sets the attribute CSA and then another constraint uses the CSA to assign a different attribute/property. In this case, you cannot guarantee it works correctly. You need to re-evaluate (that is, trigger) the constraints multiple times in order to be sure they are assigned correctly.

Hierarchical Object Rule Resolver

The following rule resolver works vertically within these hierarchies:

• First Match Wins This resolver is used in the hierarchies listed above and starts from the lowest object in the hierarchy and works its way up until it finds a matching constraint for that object and then stops. For example, a Max Wires per Splice constraint on a bundle overrides a Max Wires per Splice constraint on the harness to which a bundle belongs.

Same Level Object Rule Resolvers

If an object has multiple constraints of the same type but with different values on the same level within the hierarchy, additional rule resolvers are used to evaluate the rules:

• Max Value In this scenario, the constraint with the largest value on that level of the hierarchy overrides the other constraints on that level. Examples of numeric constraints that follow this type of rule resolver are: Minimum Splice Separation

Cost of wire per unit length

Cost of splice

For example, a bundle has a constraint Cost of splice = 5 and a constraint Cost of splice = 10. In this case, the constraint Cost of splice = 10 is used.

• Min Value In this scenario, the constraint with the smallest value on that level of the hierarchy overrides the other constraints on that level. Examples of numeric constraints that follow this type of rule resolver are: Max Wires per Splice

Max Wires per Multiterm

For example, a bundle has a constraint Max Wires per Splice = 10 and a constraint Max Wires per Splice = 5. In this case, the constraint Max Wires per Splice = 5 is used.

• Don’t Overrides Do In this scenario, any instance of a boolean constraint set to Don't overrides another instance of that constraint set to Do within that hierarchy. Examples of constraints that follow this type of rule resolver are: Place by Property

Route by Property

• Prioritized Pattern Match For constraints that set attributes or properties, the system uses a special resolver based on how closely the constraint matches the object in question. For example, if one of the constraints matches exactly (that is, with no wild-cards), then this overrides a more general match based on wild-cards. Similarly, a constraint with some normal characters and some wild-cards override the default match of .. For example: A specific match such as Name = Sig01 overrides a refined wild card value such as Name = Sig.. However, the refined wild-card overrides a broad default such as Name = .* Note After trying to resolve constraints using the Prioritized Pattern Match mechanism, the system may still not be able to determine which constraint wins. In this case, it reports an error message when evaluating the constraints.

The Effect of Collective Objects

Some rule evaluations are based on a single object hierarchy. For example if there is a Cost of Splice constraint on a bundle, the system needs to evaluate the object rule on the bundle only.

However, some rule evaluations are based on a collective rule effect of the rules on the objects on the same level of the hierarchy and those on other levels of the hierarchy.

For example:

A wire passes through a two regions on a bundle. The regions have Cost of wire per unit length constraints with different values. As a result of the regions being in the same ruled object level, the system evaluates both rules collectively using the Max Value rule resolver for objects on the same level. Additionally, the system ignores any Cost of wire per unit length constraints on other levels of the hierarchy because it uses the First Match Wins rule resolver for objects in the hierarchy.

For further information, see Evaluation of Rules on Bundle Regions and Creating a Strategy for Constraint Definition in Capital Systems Integrator.

Parent Topic:

Rules and Constraints

Capital Systems Integrator User Guide, 2512.2606

Unpublished work. © 2026 Siemens