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:

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

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:

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