Cameo2026x SysMLv2 Plugin issue quick notes

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 please know that I am most grateful for your efforts so far.

Whilst I am confident the Cameo implementation for SysMLv2 will become very powerful, as it currently stands I would not yet recommend it for use on industrial strength projects unless you have a very large organisation with a large R&D department and can absorb the time it will take for shortcomings to be addressed and spend sponsored time reporting bugs and issues. And you'll need a lot of patience!

My 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).

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. However, see remarks below about the need for "localised" textual representation code editing (instead of editing code for an entire project).

Some shortcomings AFAICT and suggestions:

This author assumes that inline parsing support is work in progress; in the meantime use the specification dialog instead.

Note concerning the above that 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).

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

---

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 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.)

---

Some feature suggestions

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.

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).

---