Cameo Power User

What Are Derived Properties in Cameo and Why Should I Care?

What Are Derived Properties in Cameo and Why Should I Care? — CameoMagic

A derived property in Cameo (CATIA Magic / Cameo Systems Modeler) is a property whose value is computed from the model instead of typed in by a person. You define the rule once — a simple navigation expression or a script — and Cameo calculates the value for every element it applies to, then displays it in compartments, tables, and matrices exactly like a hand-entered property. You should care because your model already knows the answers to your most expensive review questions, and derived properties are how you get those answers out without anyone maintaining them by hand.

Watch on our YouTube channel: MetaChain & Structured Expression Creation in Tables and Legends – 2 Examples

The question your model already knows the answer to

Here is the situation that made us believers. In our quadcopter demo model, someone in a design review asks: “Which requirements does the flight controller ultimately satisfy through its ports?”

The information is all there. The flight controller has ports. Those ports have connectors running to the ESCs, the motors, the GPS receiver, the radio link, the camera payload. Satisfy relationships hang off blocks along those paths. A patient engineer can open a dozen diagrams, follow every connector, and assemble the answer in twenty minutes.

Or the model can answer it itself, instantly, for every block at once.

That is what a derived property is for. You write the navigation logic one time — start at the block, walk to its ports, follow the connectors, collect the satisfied requirements at the far ends — and attach it as a property called something like satisfiedThroughPorts. From then on, every block in the model carries a live, always-current answer.

Two flavors: expression-based and script-based

Cameo gives you a spectrum, and it matters which end you start at.

Expression-based derived properties are the no-code end. You point and click your way through a navigation: this element, to its owned ports, to the connectors on those ports, to the element at the other end. Cameo calls a declared hop-by-hop path like this a metachain, and we wrote a whole post on them — What Is a Metachain in Cameo, in Plain English?. If your question is “follow this chain of relationships and give me what’s at the end,” an expression is all you need. No code, nothing to break in an upgrade, and anyone on the team can open the definition and read it.

Script-based derived properties are the power end. When the navigation needs a decision — only follow connectors of a certain kind, recurse through nested ports, stop when you hit a requirement — you write a short script, typically in Groovy, and Cameo runs it per element. This is real programming against the tool’s API, with real sharp edges; we catalogued the ones that bit us in What Are the Biggest Gotchas Writing Groovy Scripts in Cameo?.

Our advice: always try the expression first. Reach for a script only when the expression genuinely cannot say what you mean. And if you’d like to watch this machinery in action before building your own, our hands-on walkthrough Tagged Value Addition with OCL2.0 Script & Customization builds a scripted, customization-backed property step by step in Cameo.

They show up everywhere real properties do

This is the part that surprises people. A derived property is not a report you run; it is a first-class property of the element. That means:

  • It appears in the element’s Specification window alongside everything else.
  • It can be shown in a block’s compartment on a diagram, so the computed answer sits right on the BDD.
  • It becomes a column in any generic table — which is where it really earns its keep, because now you can see the computed answer for two hundred elements on one screen and sort or filter by it.
  • It can feed dependency matrices and be used in searches and validation.

A stakeholder looking at that table has no idea — and no need to know — that a script produced the column. To them it is simply the model telling the truth about itself.

What this replaces

Before derived properties, the answer to “which requirements does this block satisfy through its ports” lived in one of three places: an engineer’s memory, a spreadsheet exported three weeks ago, or nowhere. All three go stale the moment the model changes.

A derived property never goes stale. Move a connector from the ESC to a different port, and the computed column updates. That is the quiet superpower: it converts tribal knowledge and one-off analysis into a permanent, self-maintaining feature of the model. When we audit a team’s model health, “how many of your review questions are answered by derived properties versus by somebody’s spreadsheet” is one of the first things we look at.

The gateway drug to serious model automation

We call derived properties the gateway drug deliberately. The first one a team writes is usually modest — a count of unallocated activities, a rollup of mass through the part tree. Then the pattern clicks: the model is a database, and derived properties are queries that render as properties.

From there the same skills compound. The navigation logic you wrote for a derived property is the same logic behind a custom relation map criterion. The tables you populated become the backbone of generated documents. The team stops treating Cameo as a diagram editor and starts treating it as the system’s single source of truth that can compute things. Every serious Cameo automation effort we have seen started with somebody’s first derived property.

Getting started without hurting yourself

A few rules from experience:

  • Define derived properties in a customization inside a profile you control, not scattered ad hoc. In recent versions the customization machinery is stable and upgrade-friendly.
  • Name them like answers: satisfiedThroughPorts, unallocatedFunctionCount — not derivedProp3.
  • Start with one question your team actually asks in reviews. Do not build a library of clever properties nobody asked for.
  • Keep script-based ones few and commented. A derived property is automation, and automation without an owner is model debt.
  • Put your best ones in a table early. Visibility is what convinces the rest of the team.

Expect your first script-based property to return nothing on the first try — everyone’s does. When that happens, there is a systematic way out, which we cover in How Do I Debug a Derived Property That Returns Nothing?.

Where to go from here

If your team is answering model questions with spreadsheets and hallway memory, a couple of well-chosen derived properties will change how your reviews feel — and this is exactly the kind of capability CameoMagic builds with teams and trains their engineers to own themselves. The low-friction first step is our free 30-minute model review: bring your model, and we will point out the two or three questions it could be answering automatically. Reach out at cameomagic.com.

Go deeper: Every Report Wizard and VTL tutorial in one place, in learning order, with the common gotchas. Report Wizard & VTL tutorials →



Leave a Reply

Your email address will not be published. Required fields are marked *