Dr Darren's Cameo2026x SysMLv2 Plugin quick review notes: Tips, issues, workarounds, wishlist.

Some quick notes from Dr Darren on the Cameo 2026x SysMLv2 Plugin (as of Feb 2026). This web page will be updated (or perhaps deleted completely) as the SysMLv2 Plugin matures.

SysMLv2 specification page numbers refer to:

To the tool developers: As a long-time Cameo customer and SysML advocate (and former expert advisor to No Magic Inc) please know that I am most grateful for your efforts so far. The Cameo SysMLv2 Plugin is clearly superior to any other SysMLv2 tools currently available and is an excellent way to learn more about SysMLv2.

Whilst I am most confident the Cameo implementation for SysMLv2 will become very feature rich and powerful, as it currently stands I would not yet quite recommend it for use on industrial strength projects unless you are a very large organisation with a large R&D department and can absorb the time it will take for some of the tool feature shortcomings to be addressed and can spend sponsored time reporting bugs and issues. You should also already have trained staff with experience with SysMLv2, or engage an expert SysML/MBSE consultancy like Webel IT Australia.

And you'll need a lot of patience! Many essential aspects required for practical MBSE do not yet have convenient graphical feature support, and you'll have to know your SysMLv2 textual representation modelling code (which is a good idea anyway) and use the textual representation editor a lot.

The Cameo SysMLv2 Plugin understandably also does not yet have all of the wider MBSE ecosystem features of Cameo for SysMLv1.

My tentative recommendation for smaller organisations for now is to still use the tried and tested SysMLv1 in Magic Cyber-Systems Engineer ^® (Cameo Systems Modeler^®) (with its wider ecosystem of supporting features) and then rely later on the SysMLv1 to SysMLv2 conversion support (whilst perhaps becoming familiar with the SysMLv2 language in an exploratory spirit as a side-project). Unless, that is, you wish to invest long term in SysMLv2 from the start.

Some of the best bits about the Cameo SysMLv2 plugin so far

Whilst not as powerful as a fully-fledged IDE, the textual representation code editor is quite good. It has some degree of context awareness and prompting on elements, and collapsible groups. Pre-validation prevents synchronising against invalid sysml code, and the live parser offers some degree of help on syntax. There is also some basic code completion support for main constructs by keyword.

However, see remarks below about the need for "localised" textual representation code editing (instead of editing code for an entire project).

You'll also find that precisely because of the more integrated approach of SysMLv2, some features and menu items may at first appear to be "missing" compared with the SysMLv1 tool; this is in some cases directly because you will no longer need as many menu items because SysMLv2 as a language treats elements far more uniformly, that is, a single menu item for SysMLv2 now does a lot more work.

If you are lost try them. Note that "Features" and "Actions" here sometimes have unexpected meaning (for example you can show States with Display Actions).

Some shortcomings AFAICT and suggestions:

I assume that inline parsing support is work in progress; in the meantime use the specification dialog instead and the textual representation editor. I consider the above a priority since the classic context diagram is an important communication device. Concerning the above, there are lots of cases where the Cameo «keywords» are a bit different from the spec examples (Cameo may even be more consistent). Note concerning the above one can display an interface usage within a part def or part context symbol by dragging the interface usage relationship from the containment browser into the embedded connection view (created using Display Connections) but there is no obvious way to relate it using dashed lines to the connection as shown in p.76. Most of the information can nevertheless be displayed. Also, inline // code comments (not Comments) get deleted. It is not clear to this author whether // inline code comments are officially supported by the textual representation language but they are used liberally in the SysMLv2 specification itself and are useful, but one can always simply use Comment /* ...*/ form instead

There is a real need for portion-wise "local" editing of the textual representation code instead of having to edit the textual representation of the entire model.

The Display -> Relationships -> Display Others feature only handles some cases. For example, relationships between a timeslice and snapshot can't be created using Display Others (use Display Features on the timeslice instead).

BTW Cameo 2026x uses the verbose «individual timeslice occurence» and «individual snapshot occurence» keywords instead of «timeslice» and «snapshot» as shown on p.52 of the spec (it is not known whether Cameo is perhaps more consistent in this regard than the spec). There are quite a few other cases where Cameo SysMLv2 uses different «keywords» on symbols, but they are clear enough and this matter is considered very low priority for the purposes of this quick review.

Some textual representations from the spec that fail completely or have graphical representations that don't correspond with the spec figures.

DISCLAIMER: In the following it is NOT assumed that the spec examples are themselves consistent or correct and the tests were performed mostly "as is vs the spec examples (in some cases to make the spec examples work one has to provide an additional part or action context not always shown below).

Sometimes there are ways known to work well in the tool that are not exactly as in the spec. Please refer to the Dassault docs for the SysMLv2 Plugin for their recommendations.

---

enum = value1 [unit1];

---

action def setX(c : C, newX : Real) {
  language "alf"
  /* c.x = newX;
   * WriteLine("Set new x");
  */
}

---

Given:

package P1 { 
  item A; 
  item B;
  alias  CCC for B {
    doc /* Documentation of the alias. */
  }
  private alias D for B; 
}

The import C below fails:

package P2 {
  private import P1::A;
  private import P1::C; // Imported with name "C". 
  package Q {
    import C; // "C" is re-imported from P2 into Q. 
  }
}

The above works though if you use private import C;.

---

The following code is not represented as per p.59 with a but with a feature membership PerformActionUsage to action1:

part part0 { 
  perform action
  action1;
  perform action2;
}
action action2;

---

Representation of connection definitions "without context" as relationship lines or arrows between two part definitions does not seem to be supported (see p.65), however it might not be intended by the spec anyway that such be supported (these examples from p.65 might be "floating" code snippets):

connection def ConnectionDef1 {
        end end1 : Part1;
        end end2 : Part2;
    }

connection def ConnectionDef2 {
        end [1..1] part sourceEnd : Part1;
        end [1..*] part targetEnd : Part2;
    }

If, however, you do indeed create a part def context for each of the above example and then use Display Features it is not clear how to to display all notations shown in p.65, such as end names with multiplicities, and in the 2nd case a connection direction arrow.

---

connection def ConnectionDef3 {
  end [0..1] part end1 : Part1;
  end part end2 : Part2;
  end part end3 : Part3;
}

part def ConnectionDef3Context {
  part end1 : Part1 [0..1];
  part end2 : Part2;
  part end3 : Part3;
   connection connection1 : ConnectionDef3 connect (end1, end2, end3);
}

If you use Display Features it draws the n-ary connection ok but it displays a generated name connectionDef3 : ConnectionDef3 instead of connection1.

---

Cameo 2026x SysMLv2 fails almost completely representing this example from p.82 for «message», although the spec example may not be fully posed. All I managed to get was a black dot between two parts, with or without the events shown as features (nested view) and with or without an additional context:

part part1 : Part1 {
  event occurrence ev1;
}
part part2 : Part2 {
  event occurrence ev2;
}
message of item1 : Item1 from part1.ev1 to part2.ev2;

---

The following guard example from spec p.91 was not accepted by the code editor:

action action1 : Action1;
action action2 : Action2; 

succession action1 if guard1 then action2;

The following rewriting worked with an additional context action:

action withGuard {

  action action1 : Action1;
  action action2 : Action2;

  first action1;
  if guard1 then action2;
}

---

When attempting the following from p.97 (adapted to provide a context) Cameo 2026x seems to fail creating a scene parameter with the wrong direction for the succession flow and an extra receiver parameter.

port viewPort; 
item def Scene;
action trigger1 accept scene : Scene via viewPort;
succession flow from trigger1.scene to action2.scene;
action action2 {
   in item scene :
Scene; 
}

It may be that the spec example is ill posed. Introducing the following worked:

action trigger1 {
  out item scene : Scene;
  accept scene : Scene via viewPort;
}

---

On the complex Accept and Send Action Flow example from p.99 with a Camera and Screen, Cameo 2026x failed on a number of counts (again not asserting that the spec example code is itself correct). For example, the scene parameter on the trigger accept action was again reversed, and the picture flow from shoot to sendPicture was missing. See p.99 for the full example code.

---

I was not able to fully capture this if/then/else example from p.111 (even with added ThreatLevel enum and context etc.) Also, Cameo 2026x did not like the then:

if threat.level == high then {
  perform soundAlarm {in cause = threat;}
} else if threat.level == medium then { 
  action sendNotification {in msg = threat;}
} else {
  action beginMonitoring {in target = threat;}
}

---

The state def OnOff4 example on p.120/121 was only accepted by changing the order of the isEnabled test, and the state def OnOff5 example on p.121 with shorthands was not accepted as is.

---

For the composite state examples on p.115 Cameo gives an «entry» action instead of a start/initial state symbol.

---

The following may just be a permissible graphical representation variation point. The representation of multiplicity is "reversed" compared with the SysMLv2 spec figures. Given for example:

part part1 : Part1 [0..1];

The spec represents this as (see Graphical Notation p.38):

«part»
part1: Part1 [0..1]

Cameo represents this as:

«part»
part1[0..1] : Part1

Note however from the spec:

The multiplicity of a usage can be given in square brackets [... ] after the name part of the declaration of a usage (if it is named) or after one of the owned specialization clauses in the declaration (but, in all cases, only one multiplicity may be specified). (This allows for a notation style consistent with previous modeling languages, in which the multiplicity is always placed after the declared type.)

---

The 'use case def 'Provide Transportation' example from p.147/148 (which has an error from vehicle.drives) could only be partially captured in Cameo. Especially:

---

Some WISHLIST feature suggestions

WISHLIST: AFAICT synchronising from the textual representation editor does not sync to the repository, only saving the actual Cameo project does (which caused me some lost work at one stage). It would be nice if synchronising from the textual representation editor also performed a full save.

WISHLIST: Whilst I can see the benefit of having separate 'Show inherited' for each compartment category it would be good to have a single 'Show inherited all' override. Similar would also be useful for 'Show values'.

WISHLIST: On Mac OPTION+S performed synchronisation of the textual representation but only if you are actively in the textual representation editor. It would be nice if the same key combo worked from anywhere (such as when the focus is on a Diagram).

WISHLIST: Whilst the new table generation and customisation system is very powerful it is dire need of improved graphical support (those new to SysML are not going to manage that code based table easily).

WISHLIST: The ability to show the label (name and type) of a Port inside the Port symbol on Interconnection Views (which is explicitly supported by the spec see p.59) proved very useful for SysMLv1 and would be great to have in Cameo SysMLv2.

---