CATIA Knowledgeware and EKL Parametric Design: From Parameters to Knowledge Pattern

Introduction

If CAA RADE is the heavy artillery of CATIA customization, Knowledgeware (KW) is its parametric and rule engine — and it’s accessible to ordinary users without ever writing C++. This article is the companion deep-dive to The Complete Guide to CATIA Customization, focused on KW’s internal structure, EKL syntax, and how the five knowledge objects compose. We close with a complete reproducible parametric flange example that ties everything together.

Audience: design engineers and CAD developers who already know CATIA modeling and want to turn repeated work into parameter-driven automation.

Knowledgeware Module Landscape

Knowledgeware isn’t a single Workbench but a collection of licensed modules:

Module	Short	Capabilities
Knowledge Advisor	KWA	Parameter, Formula, Rule, Check, Set of Equations
Knowledge Expert	KWE	Expert Rules and Checks (multi-object batch rules)
Product Knowledge Template	PKT	UDF, Power Copy, Knowledge Pattern, Document Template
Product Engineering Optimizer	PEO	Optimization, sensitivity analysis
Business Process Knowledge Template	BKT	Standardized engineering templates across product lines

The most common combo is KWA + PKT: KWA handles “parameters and rules within a single part,” PKT handles “batch-replicating that parametric part into structured outputs.” This article focuses on those two; KWE/PEO/BKT are left for follow-up study.

EKL Syntax in a Nutshell

EKL (Enterprise Knowledge Language) is the script language inside KW, looking like a hybrid of BASIC and SQL. The key insight is that every variable is a real object in the CATIA model.

Type System

let length(Length)            // length with units
let count(Integer)
let flag(Boolean)
let label(String)
let myPad(Pad)                 // a Pad feature
let myList(List)

Unit-aware types are critical: Length, Angle, Mass, Volume, Density, Pressure are first-class types and EKL handles unit conversion automatically:

let l(Length)
l = 100mm
let l2(Length)
l2 = l + 2cm   // gives 120mm

Operators and Functions

+ - * /                        arithmetic
== <> < > <= >=                comparison
and or not                     boolean
"prefix" + "_" + name          string concatenation
round(x)  ceil(x)  floor(x)    math
sqrt(x)   sin(x)   cos(x)
length("hello")                string length

Referencing Model Objects

Backtick-wrapped strings are feature paths:

`Parameters\OuterDiameter`
`PartBody\Pad.1\Length`
`Geometrical Set.1\Sketch.1`

The backslash inside the quotes is CATIA’s hierarchy separator — not a Windows path.

Control Flow

if condition then
    expression1
else
    expression2
endif

let i(Integer)
i = 0
while i < 10
{
    /* ...do something with index i... */
    i = i + 1
}

/* Iterating over a collection: */
for x inside myList
{
    /* ...process x... */
}

Caveat: while / for inside loops are only available in KWE and Knowledge Pattern. Plain KWA Rules don’t support loops — a frequent stumbling block.

The Five Knowledge Objects

1. Parameter / Formula

A Parameter is an explicitly declared, named variable. Every node in the modeling parameter tree is a Parameter.

To add manually in KWA: Knowledge → Formula → Add → choose type → enter name and initial value.

A Formula binds a Parameter to an EKL expression:

`Parameters\TotalWeight` = `Parameters\Density` * `Parameters\Volume`

Formulas are live two-way bindings — change Density or Volume, and TotalWeight updates immediately. Their right-hand side is an expression only — no control flow.

Best practices:

• Use a uniform naming prefix (Param_, Geom_, Calc_) for filtering
• Always include units on unit-sensitive parameters (100mm, not 100)
• Don’t bind formulas directly to PartBody\Pad.1\FirstLimit\Length. Introduce an intermediate Parameter and have the Pad reference that Parameter — this lets you restructure parametrics without breaking geometry

2. Rule

A Rule is an event-driven block that supports control flow. Triggers on every Part update.

let nBolts(Integer)
let diameter(Length)
diameter = `Parameters\OuterDiameter`

if diameter < 100mm then
    nBolts = 4
else if diameter < 200mm then
    nBolts = 6
else if diameter < 400mm then
    nBolts = 8
else
    nBolts = 12
endif

`Parameters\BoltCount` = nBolts
`Parameters\BoltCircleDiameter` = diameter * 0.85

Strengths:

• Fully embedded in the part — survives reopens
• Reads/writes any reachable Parameter
• Rich library of built-in functions (math, string, body operations)

Boundaries:

• Cannot create new geometry (use Knowledge Pattern for that)
• In large assemblies, performance overhead matters — keep top-level Product Rules lightweight

3. Check

A Check is a Rule that returns a Boolean — CATIA flashes a warning icon when violated.

// Named Check_MinWallThickness
`PartBody\Pad.1\FirstLimit\Length` >= 2mm

Checks can carry messages:

let okay(Boolean)
let msg(String)
let t(Length)
t = `Parameters\WallThickness`

okay = (t >= 2mm) and (t <= 10mm)
msg = "Wall thickness " + t + " is outside [2mm, 10mm]"

Message(msg)
okay

Typical uses:

• Manufacturability checks (min wall thickness, max aspect ratio, allowed feature counts)
• Assembly-level conflict warnings
• “Soft enforcement” combined with Reactions — warn on violation but don’t block save

4. Reaction

A Reaction is an event responder: it listens for events on an object (modify, activate, update) and triggers an Action (an EKL or VBScript snippet).

Example: when a Parameter changes, automatically regenerate derived geometry:

// Source: Parameters\OuterDiameter
// Type:   ValueChange
// Action:
let r(Length)
r = `Parameters\OuterDiameter` / 2
`Geometrical Set.1\Circle.1\Radius` = r

Reactions are more reactive than Rules but harder to debug — long event chains lead to “why didn’t it fire?” mazes. Prefer Rules in production; reach for Reactions only when event-driven semantics are essential.

5. Knowledge Pattern: The Killer Tool for Structured Batch Modeling

This is the most powerful weapon in KW. A Knowledge Pattern lets you instantiate entire PowerCopies/UDFs in EKL Rules — effectively a modeling script.

A skeletal Pattern:

let i(Integer)
let template(PowerCopyReference)
let inst(PowerCopyInstance)
let pos(Plane)

template = `KnowledgePatternTemplates\BoltHoleTemplate`
i = 0

while i < `Parameters\BoltCount`
{
    pos = `Geometrical Set.1\BoltPositionsArray\Plane.` + (i + 1)
    inst = template -> Instantiate("Hole_" + i, pos)
    i = i + 1
}

Key concepts:

• Template: a predefined PowerCopy (use the PowerCopy tool in PKT)
• Instantiate: place the Template at a position with parameters as new geometry
• Loop: instantiate any number of times in while/for

Use cases are wide:

• Standard parts (bolts, weld points, rivets)
• Parameter-driven ribs (count and placement vary with design parameters)
• Topology generation for complex electrical harnesses

Complete Example: Parametric Flange

We’ll combine all five object types to build a flange that auto-determines bolt count, hole diameter, hole positions, and includes a wall-thickness check based on the outer diameter parameter.

Step 1: Design Parameters

Name	Type	Default	Notes
OuterDiameter	Length	200mm	Flange OD
InnerDiameter	Length	80mm	Center hole diameter
Thickness	Length	20mm	Flange thickness
BoltCount	Integer	6	Number of bolts (computed by Rule)
BoltDiameter	Length	10mm	Bolt hole diameter (computed)
BoltCircleDiameter	Length	160mm	Bolt circle diameter (computed)

Step 2: Main Rule (Rule_FlangeSizing)

let d(Length)
d = `Parameters\OuterDiameter`

// Bolt count tiered by OD
if d < 120mm then
    `Parameters\BoltCount` = 4
else if d < 200mm then
    `Parameters\BoltCount` = 6
else if d < 320mm then
    `Parameters\BoltCount` = 8
else
    `Parameters\BoltCount` = 12
endif

// Bolt diameter tiered by OD (simplified GB/T 9119)
if d < 120mm then
    `Parameters\BoltDiameter` = 10mm
else if d < 200mm then
    `Parameters\BoltDiameter` = 12mm
else if d < 320mm then
    `Parameters\BoltDiameter` = 16mm
else
    `Parameters\BoltDiameter` = 20mm
endif

// BCD = OD * 0.8 (engineering rule of thumb)
`Parameters\BoltCircleDiameter` = `Parameters\OuterDiameter` * 0.8

Step 3: Geometry Skeleton

In a Geometrical Set, manually create:

• Plane.XY as base plane
• Sketch.Outer for the outer circle (diameter bound to OuterDiameter)
• Sketch.Inner for the inner circle (diameter bound to InnerDiameter)
• Pad.Body extruding the two sketches into the flange (thickness bound to Thickness)
• Geometrical Set.BoltPositions — empty container for the Pattern to fill

Step 4: PowerCopy Template for Bolt Holes

In the PKT workbench create a PowerCopy named BoltHoleTemplate:

• Inputs: 1 Plane, 1 Length (hole diameter), 1 Length (depth)
• Output: 1 Hole feature

Step 5: Bolt Position Knowledge Pattern

let i(Integer)
let n(Integer)
let bcd(Length)
let r(Length)
let angle(Angle)
let centerPoint(Point)
let template(PowerCopyReference)
let inst(PowerCopyInstance)

n = `Parameters\BoltCount`
bcd = `Parameters\BoltCircleDiameter`
r = bcd / 2
template = `KnowledgePatternTemplates\BoltHoleTemplate`

i = 0
while i < n
{
    angle = (i * 360deg) / n
    centerPoint = pointInPlane(`Plane.XY`,
                                r * cos(angle),
                                r * sin(angle))
    inst = template -> Instantiate("BoltHole_" + i + 1,
                                    centerPoint,
                                    `Parameters\BoltDiameter`,
                                    `Parameters\Thickness` + 2mm)
    i = i + 1
}

Step 6: Compliance Check

A guard against misuse:

let dRing(Length)
dRing = `Parameters\OuterDiameter` - `Parameters\BoltCircleDiameter`
let okay(Boolean)
okay = dRing >= 30mm
Message("OD - BCD must be >= 30mm (currently " + dRing + ")")
okay

Result

The designer changes OuterDiameter alone, and the entire flange — thickness link, bolt count, hole diameter, hole positions, and the compliance check — updates automatically. That’s the real power of KW: encode design know-how into Rules and let the model enforce them.

Boundaries with Power Copy / UDF

The KW toolset also includes Power Copy (PC) and User-Defined Feature (UDF), which beginners often confuse:

Tool	Purpose	Where to author	Where to instantiate
Parameter / Rule	Parameters and logic inside one part	KWA	Current part
PowerCopy	”Geometric building block” copyable to other parts	PKT	Any part, manually or via Pattern
UDF	”Encapsulated feature” appearing as a single tree node like a Pad	PKT	Any part
Knowledge Pattern	Loop-instantiate PowerCopies in one part	KWA + PKT	Current part

Rules of thumb:

• Single-part parametrics → Parameter + Rule
• Reusable geometry across parts → PowerCopy
• Want it to “look like a built-in Pad” → UDF
• Loop-instantiate based on a count parameter → Knowledge Pattern + PowerCopy

Migrating to DELMIA / 3DEXPERIENCE

Knowledgeware module names changed on 3DEXPERIENCE:

• Engineering Rules Capture: equivalent of V5’s KWA
• EKL: the scripting language itself keeps the Enterprise Knowledge Language name on 3DX; syntax stays largely compatible with V5
• Knowledge Apps: replaces some PKT capabilities

Migration notes:

1. Document Template is deprecated; use Reference Engineering Template instead
2. EKL references to other References changed: V5 uses Product\PartBody\Pad.1, 3DX uses lookups based on PLM Reference IDs
3. Reactions are de-emphasized on 3DX in favor of platform event buses
4. PowerCopies on 3DX require explicit Inputs/Outputs semantic types — V5’s implicit conventions don’t carry over

If your team is on V5 today and plans to move to 3DX, EKL expressions are largely portable; geometry references will need rework. Concentrate rules on Parameters, minimize direct geometry references.

Enterprise-Grade Adoption

Naming Conventions

Param_<purpose>_<unit>        // e.g. Param_OuterDia_mm
Calc_<derived>                 // e.g. Calc_BoltCount
Geom_<geometric_object>        // e.g. Geom_Sketch_Outer
Rule_<rule_name>               // e.g. Rule_FlangeSizing
Check_<check_name>             // e.g. Check_MinWallThickness

A consistent prefix makes large projects much easier to reason about — at a glance you can tell user-input parameters from derived computations.

Versioning

• KW objects live inside .CATPart and cannot be diffed independently
• Recommended: export EKL text (Knowledge → Export Rules) and check it into Git alongside the CATPart
• ENOVIA / 3DEXPERIENCE users can rely on PLM versioning, but enable fine-grained versioning on KW objects

Performance Tuning

KW often becomes the bottleneck in large assemblies:

• A single Rule referencing more than 50 objects should be split
• Avoid circular dependencies between Rules (A modifies B, B modifies A)
• Don’t put heavy geometric computation inside Reaction Actions
• Put “display-only” derived values in Formulas; put “decision-driving” logic in Rules — they have different performance profiles

Integration with ERP/PDM

The last mile — exporting KW results to ERP/PDM. Common approaches:

• Automation bridge: VBA / Python scripts read Parameters and write CSV or call Web APIs
• 3DX REST API: more elegant on 3DEXPERIENCE
• ENOVIA SOA: the mature path for V5 + ENOVIA deployments

For details, see the Automation chapter in The Complete Guide to CATIA Customization.

Summary

Knowledgeware is not a “toy for advanced users” — it’s an engineering weapon for codifying experienced engineers’ design know-how into the model itself. Master Parameter / Rule / Check / Reaction / Knowledge Pattern, plus a clean naming and governance discipline, and a team can convert “drawing work” into a “fill in parameters and let the model validate” pipeline.

Further reading:

• The Complete Guide to CATIA Customization — series overview
• Creo Parametric Design Automation — cross-platform comparison
• The Complete Guide to NX Customization