Rules and Constraints

Creating a Strategy for

Constraint Definition in Capital Systems Integrator

When starting to work with this toolset, it is recommended that you create an organized strategy for defining and using constraints. This ensures the re-usability and consistency of the constraints across vehicle programs.

Do:

Assign constraints as high up the hierarchy as possible (that is, at design and harness level). This avoids duplication of constraints on multiple objects.
Define constraints that use properties/attributes specified on logical objects. This enables constraints to be very generalized and a single constraint can apply to multiple objects. Using a property defined on a symbol removes the need for an engineer to remember to add it.

Do not:

Define constraints that use object names (unless absolutely necessary). These constraints are very specific and may require constant editing and management.

Defining a Strategy

One approach to defining the initial constraints used by an organization is as follows:

Breakdown the available constraint templates into their areas of influence: Placement

Wire Routing

Wire Synthesis

Network Synthesis

Wiring Specification

Ground Design

Consider each area in turn and determine the requirements: What control do you need over the resulting objects synthesized in Capital Systems Integrator?

It may be necessary to experiment to determine how to achieve the exact control required. Custom constraints can help make this easier.

Define generically applicable constraints: Try to define default constraints that you can apply at the design level.

Try to define groups of constraints that you can apply together (for example, as a rule).

Expect to refine the constraints over time.

The following sections provide further details for constraint strategies related to particular areas of functionality.

Placement

Constraints Strategy

Placement of devices into slots is influenced by the following main constraints:

Option place by Attribute/Property
Place by Attribute/Property

By default, there is a placement rule on any design that places devices into slots with the same name.

There are limited strategies available for device placement. You can either use a name-based placement strategy or a property-based one. If possible, consider using symbol properties to drive placement as you can define these once avoiding errors. It is also good to use consistent names/properties to allow placement rules to be re-used across vehicle programs. Custom constraints can allow some additional flexibility.

Note

You can use constraints to place a device in multiple slots if each instance is mutually-exclusive. For example, a battery may be placed in a particular slot in one vehicle configuration but be placed in a different slot in another vehicle configuration. You can also use constraints to place a device in one slot multiple times using option expressions. This enables the device to have a different footprint depending on the configuration. See Variant Placement of a Device for general concept information and examples.

Wire Routing

Constraints Strategy

Wire routing is an integral part of synthesis. It is the control of which paths through a vehicle harness topology are taken by each signal. Wire routing is influenced by the following main constraints:

Route by Attribute/Property
Cost of wire per unit length (Note that wire has a cost of 1 per unit length by default)
Cost per wire for Inline/Junction Box

The first of these constraints provides an absolute method of control (for example, never use this path for this signal). You can consider the second and third constraints, when you apply them to a subset of the signals, to be a hint to synthesis (that is, prefer one path over another if possible).

These constraints are self-explanatory and not many strategies are available. However, note that the first constraint may stop synthesis from finding any solution at all. For this reason, you may want to use the other constraints where possible. The router finds the optimum route based on wire length and costs. However, the first constraint can be useful to keep classes of signal separate (for example, through parallel or similar paths).

Consider using the second constraint to limit the use of certain paths requiring expensive wire types (for example, high temperature) or where a routing channel has limited space available.

The third constraint is often used for safety or ground signals, where it is highly desirable for all connections to be made within a single harness.

Wire Synthesis

Constraints Strategy

Achieving the required synthesis solution in terms of numbers and positions of splices and multi-terms can be the most challenging part of defining constraints. Wire synthesis is influenced by the following main constraints:

Cost of splices
Cost of wire per unit length
Cost of multiterm
Cost per wire for Inline/Junction box
Max Wires per Multiterm
Max Wires per Splice
Minimum Splice Separation

The first two constraints are used to trade-off wire length against splice cost. They provide the major control over splice creation. By default, the system assumes that the cost of a splice is zero and that the cost of wire per unit length is one. This means, it uses as many splices as necessary to ensure that there are no overlapping wires in a signal (resulting in a splice at every harness takeout where three wires are required). As the cost of splice increases (in relation to the cost of wire per unit length), the system tends to reduce the number of splices and increase the amount of additional wire. If, for example, two splices were initially placed at takeouts 100 units apart, you would need the cost of a splice to be100 times greater than the cost of a wire per unit length before the system would effectively combine these splices (that is, use one splice instead of two).

The Cost of multiterm constraint is similar but it controls the trade-off between splices and multi-terms. As indicated above, as splice cost increases, the system tends to increase the amount of overlapping wire. This can lead to multi-terms being created in preference to splices. This constraint reduces that tendency (although typically multi-terms are prohibited by the majority of cases using the Max Wires per Splice constraint).

The Max Wires per Multiterm and Max Wires per Splice constraints are usually defined based on physical or mechanical requirements (for example, splice parts available). They are often used to provide differing control for signal classes (for example, power and ground can be multi-termed, but other signals cannot). These constraints can also be used to prohibit splices or multi-terms completely (for example, no splices in a wet harness).

The Minimum Splice Separation constraint may only require a single default rule (on the design) to define allowable spacing.

Network

Synthesis Constraints Strategy

Networks (such as LIN, CAN or FlexRay) typically require very specific synthesis constraints to ensure the generated wiring adheres to the network specification. Four constraints are available:

Network termination Allows you to specify whether wiring synthesis sets logical pins as IxO Terminated to identify network ends.
Network Specification Controls the routing of multicores or signals in a backbone network.
Daisy-chained network specification Controls the routing of multicores or signals in a daisy-chained network.
Daisy-chained network group Allows you to specify pins that belong to network groups.

See either Backbone Networks in Wiring Synthesis or Daisy-chained Networks in Wiring Synthesis for more detailed information (including examples) about object attributes and constraints that you use to control network synthesis.

Wiring

Specification Constraints Strategy

Wire specification is influenced by the following constraints:

Wire Specification
Splice Separation
Multicore Specification
Terminal Type Specification
Length change for Wire

When defining these constraints, it is important to consider all downstream requirements. In the majority of cases, it should be possible to use defaults (for example, on the design). For example, a single constraint can set a wire attribute based on a value specified on the logical net. Wherever possible, apply constraints to classes of signals (for example, using properties). This provides a straightforward mechanism for engineers designing systems to assign a meaningful value to an object, without having to be concerned about the resulting behavior in Capital Systems Integrator.

Parent Topic:

Rules and Constraints