Newer Version Available
Relationships
Here is a comprehensive overview of relationships, their syntax, purpose, and key features, particularly utilizing examples relevant to the Generator Set model.
Definition and Syntax of Relationships
Relationships define the one-to-many connections between a parent type (such as a bundle) and its component types (children).
- Keyword: The keyword used is relation.
- Syntax: A basic relationship declaration includes the relation name, the target type,
and cardinality
bounds.
1relation <relation name> : <Target Type>[min..max] { /* Optional content */ } - Purpose: Relationships represent the product structure in a bundle. For example, the root product (GeneratorSet) has relationships with its components (MainAlternators, TemperatureSensors).
Omit Unnecessary Relationships
When using the visual builder or the CML editor to create a CML code for a bundle, the system by default imports all the relationships for the selected bundle from the structure defined in Product Catalog Management (PCM). In large and complex CML code, some of these relationships may not be relevant to any constraint and can be potentially omitted.
To enable import of a subset of bundle components, add this property at the top of the constraint model CML file.
1property allowMissingRelations = "true";If your PCM bundle contains many different relations but your CML code defines only one, the engine will validate the model but this often results in a configuration run-time failure. By setting allowMissingRelations = "true", you do not have to define every relation found in the PCM (such as GeneralModels in the Relationship Ordering example) if they do not require specific configuration logic in your CML file.
Here’s an example with allowMissingRelations property.
1// 1. Enable skipping of unneeded relations from the Product Catalog (PCM)
2property allowMissingRelations = "true";
3
4type ConciseGeneratorBundle {
5 // Define only the specific accessory needed for this logic
6 relation enclosures : Enclosure;
7
8 // A simple variable to trigger the logic
9 int requiredKW = [100..5000];
10
11 // Logic: High power requirements force a specific enclosure type
12 // This omits other accessories like filters, batteries, and heaters [2, 3].
13 constraint(requiredKW > 2000 -> enclosures[ReinforcedEnclosure] == 1,
14 "Power levels above 2000kW require a Reinforced Enclosure.");
15}
16
17// 2. Define the accessory and its specific subtype
18type Enclosure ;
19type ReinforcedEnclosure : Enclosure;For more information, see Constraints.
To ensure run-time stability without the allowMissingRelations property, you must manually define every single relation and type present in the PCM bundle, even if you don't intend to write logic for them. This creates large CML files with a high number of variables and components, which lead to performance degradation, and even timeout issues.
1// EXPENSIVE FIX: Mirroring everything
2type GeneratorSet {
3 relation engineModels : EngineModel; // Unused in CML logic
4 relation alternators : Alternator; // Unused in CML logic
5 relation fuelFilters : FuelFilter; // Unused in CML logic
6 relation starterMotors : StarterMotor; // Unused in CML logic
7 relation enclosures : Enclosure; // The only one we need
8 // ... potentially 15+ more relations ...
9
10 constraint(requiredKW > 2000 -> enclosures[ReinforcedEnclosure] == 1);
11}
12type Enclosure ;
13type ReinforcedEnclosure : Enclosure;Order Keyword
The order() keyword is used within a relation declaration to define the specific sequence in which the constraint engine evaluates and attempts to instantiate the child subtypes available in that relationship. This controls the prioritization of component selection.
Example: Relationship Ordering
1// --- Component Subtypes (Specific Generator Models) ---
2// Define a base type for generator models with a power attribute
3type GeneralModel {
4int powerKW = [0..3000]; // Explicit domain
5}
6// Specific subtypes that inherit from GeneralModel
7type GeneralModel2500 : GeneralModel {
8int powerKW = 2500;
9}
10type GeneralModel1750 : GeneralModel {
11int powerKW = 1750;
12}
13type GeneralModel900 : GeneralModel {
14int powerKW = 900;
15}
16// --- Parent Type (GeneratorSet) ---
17type GeneratorSet {
18// Required power defined by the parent (non-configurable)
19@(configurable = false)
20int requiredKW = [100..3000];
21// Relation Declaration using order()
22// Cardinality requires exactly one model to be selected.
23// order() sets the selection priority (2500 KW model is checked before 1750 KW model).
24relation GeneralModels : GeneralModel order(GeneralModel2500, GeneralModel1750, GeneralModel900);
25}