Modeling in Cameo for the Xcelerator Digital Thread

1Onboarding & Overview

1.1 What this guide is, and isn't

This is a modeling guide. It tells you what to build in Cameo and why. It is not a Cameo training manual (it won't teach you the software's menus from scratch), and it is not a tool administrator's guide (it won't tell you how to configure the connector between systems).

It exists because there is a real gap between how Lockheed has been modeling for the last ten years and how this guide asks you to model going forward. That gap matters enough that we explain it directly, in Section 1.4, instead of glossing over it.

Every technical claim in this guide comes from real working sessions between the Lockheed and Siemens teams building this connection, not from a manual or a guess. Where something is still unresolved, we say so plainly instead of pretending it's settled.

1.2 The big picture: three tools, one thread

Three systems work together to take a design from an idea to a finished electrical architecture.

Cameo is where a systems engineer designs the system: what it's made of, and what it does. This is where your work starts.

Teamcenter is the backbone. It stores the design, connects it to everything else in the program (requirements, other disciplines, change records), and acts as the single source of truth.

Capital is where the electrical architecture, the actual wiring, signals, and components, gets designed, based on what came from Cameo through Teamcenter.

   Cameo  ▶▶▶▶▶▶  Teamcenter  ▶▶▶▶▶▶  Capital
 (design intent)      (system of record)     (electrical realization)
      ◀◀◀◀◀◀◀◀◀◀◀◀◀◀◀◀◀◀◀◀◀◀◀◀◀◀◀◀◀◀◀
                (some information flows back)

A tool called the HCL Cameo-Teamcenter connector sits between Cameo and Teamcenter and does the actual moving of data. You don't operate it directly very often; mostly you'll see two buttons: Mark for Deep Sync and Put Model. When you mark something and put it, the connector reads your Cameo model and pushes what it finds into Teamcenter, following rules set up by your PLM administrator.

1.3 A few words you'll see everywhere

Full definitions live in the Glossary, but here are the load-bearing ones up front.

• Model: the Cameo file you're building. It represents your understanding of the system.
• Function: something the system does. In Cameo, you model this as an Activity.
• Logical block: something the system is made of. In Cameo, you model this as a Block.
• Port: a connection point on a block, where something goes in or out.
• Allocation: the link that says "this function is performed by this block."
• Digital thread: the connected, traceable path of information from Cameo, through Teamcenter, into Capital, and back.

1.4 Where Lockheed stands today, and why this guide exists

Here is the honest picture, worth reading carefully, because it explains the whole reason this guide exists.

For roughly the last ten years, on both the Wildfire program and the Quick Start Data (QSD) program, Lockheed's Cameo-to-Capital connection has worked by feeding only one kind of information downstream: part properties, the structure of the system, the "bag of parts and ports" you build in an Internal Block Diagram. It has never fed Activities, the behavior, the functions the system performs, into Capital at all.

Rich Morrell, on the Siemens side, has been trying to change this for more than five years. This guide is that change. It is not a description of how things have always been done. It is a new, more complete standard: one where both structure (what the system is made of) and behavior (what the system does) cross the bridge, consistently, instead of only structure.

Lockheed does have its own internal modeling methodology, nicknamed M³ (also called MBSC), documented on an internal Confluence site. But by its own documentation, it is not mandatory. Programs are explicitly told to fall back to their own tailoring guidance when M³ doesn't fit. The result, in Rich Morrell's own words, is "kind of the Wild West": every program modeling somewhat differently. This guide's real job is to give every program the same, defensible answer to "how do I model this so it survives the trip downstream," instead of leaving each one to improvise.

If you've been modeling with part properties only for years, you are not doing anything wrong; you were following the only path that existed. This guide adds the missing half.

1.5 Who does what

2Value to Lockheed: Reducing Design and Change Cycles

2.1 The problem today, stated plainly

There are two real, specific problems, not hypothetical ones.

First: behavior has had no path downstream at all. Everything about what the system does, every Activity diagram, every function, has lived in Cameo and stayed there. Only structure made it into Capital. If an electrical architect needed to understand what a component was for, that understanding lived in someone's head or in a document, not in the connected model.

Second: even where data does cross today, it's easy to make it look connected without it actually being meaningful. During one of the working sessions behind this guide, an early AI-assisted attempt to link a function to the block that performs it used a plain Allocate relationship, a valid SysML element, but, in Mike Crist's words, "the cheesy way of doing it, not invalid, it's just not semantically rich." A model can look wired together in Cameo and still fail to carry real meaning once it crosses into Teamcenter and Capital. Section 3 shows how to avoid that trap.

2.2 What correct modeling actually buys you

It catches broken designs before they become invisible. Capital already has a rule that every signal needs at least one input and at least one output: if a function only has outputs connected, or only inputs, Capital flags it as an error. Cameo has a matching kind of check: if a port's declared flow direction disagrees with how you've drawn an item flow using it, Cameo will tell you. Mike Crist's summary of what happens without these checks: without a real input pin wired to a real flow, "you're sitting in a closet in the dark, nothing happens." Modeling correctly turns a silent, invisible gap into an error you catch on your screen, in Cameo, instead of a mystery an electrical architect discovers weeks later.

Behavior finally gets a path to Capital. Once your Activities are modeled the way Section 3 describes, the functions you already design in Cameo become real Capital functions automatically; nobody has to re-enter them by hand on the Capital side.

One standard, not eleven programs each guessing. Because Lockheed's own methodology isn't mandatory, the single biggest value this guide offers is consistency: every program gets the same answer to "how do I model this correctly," instead of each one inventing its own convention and discovering the differences the hard way during an integration.

Where this shows up across the design cycle. The earlier a function or a connection is modeled correctly, the earlier a broken design gets caught, during architecture work, not during detailed design, and never after the fact during a costly change. That's the whole logic behind reducing design and change cycle time: catch it in Cameo, where it's cheap to fix, not downstream, where it isn't.

2.3 Honest caveats

This connection is real and working, but it is not a finished, closed system, and it does not replace engineering judgment. As of the working sessions behind this guide, two things were still genuinely open:

• There is no Teamcenter object today that can hold a function's full pin/signature information (its inputs and its return value). Extending Teamcenter's data model to add one is being actively weighed against other priorities; it is not yet decided.
• Whether Cameo's flow-direction validation check works reliably for both of the two valid modeling styles described in Section 3.3 was not yet confirmed.

Some information will never cross the bridge, by design, not by accident. Section 3.6 lists exactly what, and why. That's not something to report as a bug.

3How to Model in Cameo to Feed the Xcelerator Process

3.1 The one idea to hold onto

The bridge only carries what you model explicitly and consistently. If you build it right in Cameo, it lands right in Teamcenter and Capital. If you skip a step, or use a shortcut, that gap doesn't announce itself; it just quietly doesn't show up downstream. Model discipline in Cameo is the whole game.

3.2 What to model, element by element, and what it becomes

The same table as above, laid out by layer. The highlighted boxes are the flow-property and item-flow objects from Section 3.3, which used to collapse into one Teamcenter object (a real defect) and have since been fixed to stay distinct there while still converging into a single Capital signal.

3.3 The two valid ways to model "what flows," and why they need to agree

SysML gives you two legitimate ways to show what moves across a connection. Lockheed teams currently use both, inconsistently, without necessarily realizing there's a difference.

Style 1, flow-property style. You define a flow property on the Interface Block that types your port. Once the port is typed, what it conveys is implied automatically. This is the complete, SysML-intended way to do it. Rich Morrell estimates roughly 30% of aerospace programs model this way.

Style 2, item-flow style. You draw an explicit Item Flow directly on the connector and assign what it conveys by hand. About 70% of aerospace programs default to this. Used by itself, without a flow property behind it, this is an incomplete model: you're describing the instance without ever having described the specification it's an instance of.

The rule to follow: do both. Type your ports with an Interface Block that declares real flow properties, and draw the item flow on top. Cameo will validate that the two agree, for example, it will stop you from showing data flowing from a camera to a processor if the interface block only permits the reverse direction. Which style you started drawing from shouldn't matter for what shows up in Teamcenter or Capital; if it does, in practice, that's a bridge defect worth reporting, not something to work around by hand.

3.4 The hardest part: wiring a function's data to real structure

Read this section twice. It covers the one genuine gap in SysML itself, not just a Cameo quirk.

There is no official SysML answer for how a pin on an Action (a function's data slot) should connect to a port on a Block (a piece of real structure). Mike Crist, who has worked this problem for years, put it directly:

"Identifying the relationship between the pin and the port on the logical element is unclear. This is the part that sucks."

Nothing in the standard tells you the "right" way to do this. The convention below is what the working group actually settled on, live, and it's the one this guide asks you to follow.

Data moves through Pins. An Action has input pins and output pins: these represent the specific pieces of information going into or coming out of that one step. Pins are not ports, and they don't live on a Block; they live on the Action.

To connect a function's data to real structure, do this:

1. Create a real Port on the logical Block or Part that performs the function.
2. Type that port with an Interface Block, exactly as you would for any structural connection (Section 3.2).
3. Wire the Action's pin to that port.

There are two separate wirings here, and they are not the same thing:

• Data wiring: pin ↔ port. This is what information moves.
• Control wiring: Send/Accept Signal Event ↔ swim-lane allocation. This is when, or whether, the function runs at all.

Do both. Neither one substitutes for the other.

Do not rely on a bare Allocate relationship as your only link between a function and the structure that performs it. It's a valid SysML element, and Cameo won't stop you from using it. But it doesn't carry the data/control distinction above, and the working group explicitly flagged it as too thin to trust for anything that needs to be real downstream.

3.5 A modeling checklist

Before you Mark for Deep Sync, check your model against this list.

• Every Activity starts with an Accept Event Action and ends with a Send Signal Action. (An activity that just "runs once when the system turns on," with nothing triggering it, is not a properly modeled function.)
• Every function-to-structure allocation is done by dragging the instance into a swim lane, not left as a bare Allocate relationship.
• You've modeled down to the leaf Action and stopped there; you haven't tried to model the steps underneath a leaf function.
• Every port is typed with an Interface Block, and that interface block declares a real flow property, even if you're also drawing an explicit item flow.
• Every function that touches structure has both its data wiring (pin ↔ port) and its control wiring (signal ↔ swim lane) done, not just one.
• Every port has a unique ID, even across different owning blocks. (A duplicate ID doesn't throw an error; it silently mis-wires. This is the single easiest mistake to make and the hardest one to notice.)
• Each function is owned by one block wherever your design allows it. (Sharing a function across multiple blocks breaks a clean, one-to-one translation downstream.)
• Your composition hierarchy (parent/child structure) is built out explicitly, not left as a flat list of blocks.
• Every tagged value you're depending on has a matching entry in the Teamcenter mapping file. If you haven't checked with your PLM administrator, assume it isn't mapped yet.

3.6 What deliberately never crosses, and why that's fine

Some things are dropped on purpose. This isn't something to report as broken.

• Pins on individual Actions inside an activity (as opposed to Activity Parameter Nodes at the activity's outer boundary) are implementation detail. Capital doesn't need to know the internal steps of how a function gets its work done, only what goes in and what comes out overall.
• Forks and joins, as control-flow structures, are ignored entirely by the HCL connector. The data or object flow passing through them still crosses (via the pin/port convention in 3.4); it's only the fork/join branching logic itself that's dropped.
• Sub-tasks beneath a leaf Action are never captured. That level of detail belongs to the software or electronics team that implements the function; forcing it into your Cameo model doesn't help them and isn't consumed by anything downstream.
• Any tagged value without a mapping-file entry goes nowhere. This is a configuration gap, not a modeling one; talk to your PLM administrator if you need one added.

4Worked Example: The "Gimbal" Model

This example is real. It's a step-by-step reconstruction of a live modeling session, not a made-up scenario. It builds a small camera gimbal system with five components: Camera, Azimuth Motor, Elevation Motor, Image Processor, and Housing. The Camera-to-Image-Processor thread was carried all the way through, structure and behavior both, and is proven to work. The other three components are still stubs, a good next exercise once you've followed this one.

Part A: Build the structure

1. Create the five logical Blocks: Camera, Azimuth Motor, Elevation Motor, Image Processor, Housing.
2. Create an Internal Block Diagram (IBD). Do this by right-clicking the Block itself (for example, the top-level Gimbal block), not the package that contains it. (Getting this backwards is an easy mistake: right-clicking the package instead creates a stray extra block you'll have to delete and start over.)
3. When Cameo asks which composed parts to automatically add to the new diagram, select all five. This creates one instance of each, you'll see them labeled like camera : Camera (instance name, then type). The multiplicity on each composition relationship controls how many instances get added; leaving it unset defaults to one.
4. At this point, your diagram is just five unconnected parts, Mike Crist's term for it: "a bag of parts." Nothing is wired together yet.
5. Add a proxy port named "image out" (direction: output) on the camera instance, and another named "image in" (direction: input) on the image processor instance. You can add a port by hovering directly over the instance in the diagram.
6. Create an Interface Block named "HDMI" to type both ports. Apply it either by dragging the interface block onto the port in the diagram, or, the easier way, by opening the port's Specification dialog and setting its type there.
7. Set each port's direction in the Specification dialog. If direction isn't available there, fall back to setting it through the item flow instead, or mark the port conjugated: a conjugated port flips the interface's normal direction, which lets you reuse one interface definition on both ends of a connection.
8. Create a Block, not a Signal, named "Raw Image" to represent the actual image data. This block is what the item flow will carry.
9. Draw the Item Flow on the IBD, from the camera's "image out" port to the image processor's "image in" port, and set it to convey the "Raw Image" block.

Part B: Build the behavior, and wire it to the structure

10. Create the Activity "Process Image," with two swim lanes: one for the camera instance, one for the image processor instance.
11. Create two Signals: "Capture Image" (triggers the camera to start) and "Image Transmitted" (announces that the transfer finished). Remember: a signal carries a trigger event, not data.
12. In the camera's lane: place an Initial node, then an Accept Event Action ("Capture Image," triggered by the Capture Image signal), then an action called "Capture Image" (give it an output pin for the raw image), then an action called "Transmit Image" (its input pin receives from Capture Image's output pin, and it produces its own output pin going forward).
13. After Transmit Image, add a Fork node, not a Decision node. A fork waits for everything coming into it, then fires all of its outputs at once. A decision node is different: it's non-blocking and only takes one path. This is a common early mistake; even the person recording this walkthrough said "decision node" out loud and had to correct himself.
14. Fork branch A: a Send Signal Action ("Image Transmitted"), followed by a Flow Final node (this ends branch A only, not the whole activity).
15. Fork branch B: crosses into the image processor's swim lane, to an action called "Process Image," followed by an Activity Final node (this ends the whole activity).
16. Watch for this gotcha: the data (object flow) coming out of Transmit Image does not route through the fork. A fork only carries the control-flow split, and it cannot accept a second input. Wire the data pin directly from Transmit Image's output pin to Process Image's input pin, going around the fork.
17. Wire the activity's pins to the matching IBD ports, following the convention from Section 3.4; this is what ties your behavior model back to your structure model.
18. Save your model, then run Analyze › Validate to catch anything wrong before moving on.

Mistakes made (and fixed) during this session, learn from them

5How the Data Flows: Cameo → PLM → Electrical Architecture

5.1 What each system owns

• Cameo owns design intent: both structure and behavior.
• Teamcenter owns the system of record: the backbone everything else connects to.
• Capital owns the electrical realization: the actual wiring and components.

5.2 The connector in the middle

The HCL Cameo-Teamcenter connector does the work of moving your model from Cameo into Teamcenter. In practice, you'll interact with it through two actions: Mark for Deep Sync (flags what should be synced) and Put Model (actually pushes it). What happens next is governed by the Teamcenter mapping file, a configuration your PLM administrator owns, which decides which attributes cross, and in which direction.

5.3 What crosses, what needs configuration, and what never crosses

5.4 The round trip

Information doesn't only flow one way. Parameter definitions start in Teamcenter and get dragged into Cameo, not the other way around, when you want goal/min/max values on a Cameo value property. For ordinary attributes, the mapping file's direction setting decides whether updates flow Teamcenter → Cameo, Cameo → Teamcenter, or both, attribute by attribute.

5.5 The honest state of automation today

As of the working sessions behind this guide, the team had just found and fixed a real defect: item flows and flow properties were being collapsed into a single Teamcenter object, which lost the distinction between a specification and an instance. That fix was re-validated against the Camera to Image Processor example from Section 4 in the same session. Two things remain open: whether Cameo's direction-consistency check behaves the same way for item-flow-only models as it does for flow-property-typed ones, and whether Teamcenter's data model should be extended to hold function pin/signature information at all.

6Appendix

6.1 Glossary

Block

A definition of a thing (a type). Not yet a specific instance of anything.

Part / Instance

One real occurrence of a block, shown in diagrams as name : Type.

Internal Block Diagram (IBD)

Shows what's inside a block: its parts, its ports, and how they connect. Create it starting from the block itself, not from the folder it lives in.

Port

A connection point on a part, where something goes in or out.

Proxy Port

The common kind of port used on parts; created by hovering over the instance.

Conjugated Port

A port that flips the interface's normal direction, so one interface definition can serve both ends of a connection.

Interface Block

Defines the "shape" of a connection, the way a plug type defines what can be plugged into it. Used to type a port.

Flow Property

The specification of what a typed port is allowed to carry. It has no real instance until an item flow actually uses it.

Item Flow

The actual conveyance across one specific connector, the real, instance-level counterpart to a flow property.

Signal

An event, like a doorbell. It triggers something to happen. It is not the data itself.

Classifier

The general term for any block, interface, or signal type. "A classifier flows across the item flow" usually means a real, data-carrying block, not a signal.

Activity

A diagram of the steps something does, in order. The leaf-level action inside it is the function.

Activity Parameter Node

A pin sitting at the outer boundary of the whole activity, its overall signature. This crosses downstream, unlike pins on individual actions inside it.

Swim Lane

Groups actions in an activity diagram by who performs them. Dragging an instance into a lane is how you allocate a function to the structure that performs it.

Accept Event Action

An action that waits for a signal to arrive before it does anything.

Send Signal Action

An action that fires off a signal.

Control Flow

The arrow that says "this step happens, then that one." It sequences actions.

Object Flow

The arrow that shows data moving from one pin to another as the activity runs.

Pin

A small input or output slot on an action, representing one specific piece of data.

Fork Node

Splits one flow into several. Waits for its one input to complete, then fires all of its outputs at the same time.

Join Node

The opposite of a fork: waits for every incoming branch to arrive before continuing.

Decision Node

A branch point that takes one path without waiting for anything else.

Merge Node

The opposite of a decision node: multiple paths come together without waiting for all of them.

Value Property

A parameter or spec value on a block. In Cameo, it only ever holds a default value, unless Teamcenter pushes goal/min/max values in.

Tagged Value

Metadata attached to an element through a stereotype's tag definition. Equivalent to a Teamcenter attribute, but only once it's explicitly mapped.

Allocate Relationship

A valid, but minimal, way to link a function to structure. Prefer the pin/port-plus-swim-lane convention in Section 3.4 for anything that needs to carry real meaning downstream.

Mapping File

The Teamcenter-side configuration that controls which Cameo elements and attributes cross the bridge, and in which direction.

Digital Thread

The connected, traceable path of information from Cameo, through Teamcenter, into Capital, and back.

HCL Cameo-Teamcenter connector

The tool that actually moves data between Cameo and Teamcenter, triggered by Mark for Deep Sync and Put Model.

6.2 Frequently Asked Questions

6.3 Open Items Still Unresolved

These were genuinely undecided as of the working sessions this guide is grounded in, not settled facts being withheld.

• Whether to extend Teamcenter's data model (BMIDE) to hold a function's pin/signature (input and return value) information. An active resourcing tradeoff, not yet decided.
• Whether Cameo's flow-direction validation check reliably applies to item-flow-only models, the same way it does for flow-property-typed ones.
• Confirmation on whether individual-action pins could be supported through some other extension mechanism; this question was asked of the connector vendor (HCL) but not yet answered as of the last working session.
• Lockheed's existing HCL-connector test activity diagrams reportedly already exist internally but had not yet been shared with the Siemens team as of these sessions.
• Lockheed's internal Confluence documentation on current, informal activity-diagram practice was still being gathered for the group to synthesize against.

6.4 Where to Get Help

Placeholder: to be filled in with real names and roles, who owns the HCL connector configuration, who to contact about Capital-side mapping questions, who owns the Teamcenter BMIDE data model.