Wednesday 29 December 2021

IBM Engineering Rhapsody Tip #101 - Transition Label toolbar tips and tricks

This is one for those Rhapsody cureos out there, as it is something that I only recently discovered (like this week!) and I think is genuinely useful, which is the ability to add a Transition Label tool to the activity diagram (which does not have it by default). The video first shows how the Transition Label tool works on statecharts (state machine diagrams) and then goes on to how it can be added to the default activity diagram toolbar. Arguably it's even more useful for the activity diagram as it removes clicks when adding guards to transitions coming out of a control flow. Anyway, I'll let you decide. Have fun.

Here's the transcript for those that need it:

I was recently documenting the drawing toolbars for some client docs, and my attention was drawn to the statechart's Transition Label tool (I've rarely used).

When you first draw a transition between states, you get a "first time" opportunity to type its text. Feature like Intellivisor (Ctrl+Space) are available.

If you don't type anything then you lose the opportunity.

Options are to right-click and use Select Trigger to select a trigger (which you can then edit). More commonly users will open the Features General tab for the transition to enter the information.

The Statechart's Transition Label tool enables you to get edit mode back on a transition with no text. When you click on a transition with no text, the Transition Label tool gives you the text editor back.

The Transition Label is a useful tool in the Statechart's armoury therefore, so why not make it a useful tool in the Activity Diagram toolbar as well?

One of the side effects of moving to online delivery of my training has been that I get to watch people's screens when they're using Rhapsody.

A common task in activity modeling is putting guards on control flows coming out of decision nodes using the Features window. It's a bit of a faff to be honest.

The Activity Diagram drawing toolbar does not have a Transition Label but why not add it, I thought?

As no other customizations are present, I'll quickly show it works by locally overriding the General::Graphics::ActivityDiagramToolbar property. Here it is! and it works!

Since I rarely use Rhapsody without customisations, I've just added it to the textual activity diagram toolbar in my ExecutableMBSEProfile. This diagram is based on a new term stereotype. Its toolbar is defined using different a different set of properties (I update these using a metamodel & associated profile nowadays).

I can complete the diagram without using the Features window now! How cool is that? ;-)

Interested in Rhapsody training/customizations then feel free to email me.

Tuesday 28 December 2021

Update to create V13 of IBM Rhapsody UML/SysML training material

Having left IBM as technical specialist for Rhapsody in 2015, I have been creating and delivering my own training material specialising in Rhapsody. I've just worked my way through a update cycle to create a Version 13 of my material. Key updates were:

- Re-naming of labs to reflect the more common order I've been settling on for delivery. This involves making sure most valuable/popular labs are given focus in initial choices for a 3 day delivery.
- Added a bit more differentiation to the Rhapsody Gateway labs with DOORS and Microsoft Word by making customisation of the Gateway Type an extension exercise at the end (i.e. still got expert tips and tricks but can also be used with simple users who don't need the expert bit).
- I simplified / shortened the sequence diagramming to make it shorter but retain the core knowledge (as the latter can be a bit heavy going for users completely new to SysML/UML).
- Added more differentiation to the ports and interfaces lab to make the conversion to proxy ports an extension exercise at the end (i.e. still got expert tips and tricks but can also be used with simple users who don't need the expert bit).
- Validate the material against IBM Engineering System Design Rhapsody Version 9.0.1 Editions with Jazz 7.0.2 server / DOORS 9.7.

The following is an example of a 5 day delivery for software engineers (and systems):

Mastering IBM Engineering Rhapsody in C++ - Sample Agenda V13 - 5 day (incl. Test Conductor)




Day 1 (Core)

Rhapsody user interface essentials and advanced

·         Focused understanding on controlling Rhapsody user interface.

·         Understand how projects are stored and how to open them.

·         Controlling the user interface to navigate around projects

·         Moving around and zooming in and out of diagrams, incl. full screen.

·         Navigating between elements, e.g., structural to behavioural.

·         Appreciation of delete from model vs delete from diagram.

·         Appreciation of how set-up effectively with profiles and properties.


Use Cases and requirements

·         Creating a model from scratch, including properties and profiles.

Practical Labs:

Lab A1: Controlling the Workspace

Lab A2: Controlling the browser

Lab A3: Creating a use case diagram

Lab A4: Use case activity modeling

Lab A5: Features and Zoom toolbar (ext)

Day 2 (Core)

Requirements and tables/metrics

·         Understand Rhapsody’s integrations with requirements managed via Gateway synchronizer (Word, Excel, “classic” DOORS) and/or

·         Overview of IBM Jazz platform and remote requirements (demo); OSLC links to Jazz, RTC Eclipse, accessing models by web-client for review purposes etc.

·         Requirement traceability essentials.

·         Appreciation of tables and matrices and what they are used for.


Composite structures

·         Understanding relations in UML/SysML: composition, association, generalization, aggregation, dependencies.

·         Controlling compartments and associated display options.

·         Tips for getting diagrams out of Rhapsody quickly and printing.

·         Linking elements with hyperlinks and enabling quick navigation.

·         Searching projects and using queries to filter the browser.

Practical Labs:

Lab B1: Rhapsody Gateway with Word

Lab B2: Rhapsody Gateway with DOORS

Demo: DNG/Jazz demo.

Lab B3: Properties and Profiles

Lab B4: Requirement tables and matrices

Lab C1: Modeling structure

Lab D3: Searching and Linking (ext)


Day 3 (Core)

White-box and architectural modeling

·         Understanding use of composite structure for hierarchical decomposition of systems, including ports, parts, and connectors.

·         Sequence diagram modeling for defining interfaces.

·         State-machine modeling and animated sequence diagrams.

·         Understanding state-chart syntax: Nested/Parallel states and patterns for usage.

·         Understanding difference between port types, pros and cons.

Practical Labs:

Lab C2: Interaction modeling

Lab C3: State machine modeling

Lab C4: Ports and Interfaces

Lab D1: Elaboration Use Cases

Lab D2: Executing System Behavior

Day 4 (C++ Case Study)

Code generation workshop in C++

·         Understanding model-driven development with code generation by building up a working example in C++.

·         Using Rhapsody Model Manager / DOORS NG.

·         Appreciation of dynamic-model code associativity.

·         Appreciation of requirements capture and traceability.

·         Appreciation of Object Execution Framework and state-charts.

Practical Labs:

Lab S1-17: Building a model

Day 5 (C++ Case Study)

Test Conductor

·         Workshop using TestConductor with a model.

Catch-up/overflow topics:

·         An of how projects can reference other projects.

·         An appreciation of how project units work in conjunction with Model Manager, role of Rhapsody DiffMerge etc.

·         An appreciation for options for document generation and html output.

Practical Labs:

Labs S18-S20: Test Conductor workshop

Lab U1: Navigating Rhapsody Units

Lab U3: Referencing External Units

Lab U4: Handling Unresolved References

Lab U5: Rhapsody DiffMerge


Monday 29 November 2021

Changes logs for SysMLHelper profile V4.0.b-V4.0.m now listed

For the last year, I've been re-writing the SysMLHelper to move functionality to the newer ExecutableMBSE profile model structuring method (using new term packages). I've just posted the enhancement list to my other blog, in case you're interested:

Making Executable MBSE fun with IBM Rational Rhapsody

It is a fairly big re-write, particularly with the way that the profile is architected, including the inclusion of a metamodeling profile that I created, and improved protection when using multiple Rhapsody instances and avoidance of passing Rhapsody elements between Java threads.

Current version is 4.0.m. However, I've held off posting profile to Github; choosing instead to work with clients and contacts directly so that I can improve it with a real focus on usage. 

Monday 25 October 2021

Model Based Risk Analysis with RAAML in IBM Engineering Systems Design Rhapsody

This looks interesting. Basically Andy L has developed a Risk Analysis and Assessment Modeling language (RAAML) profile for Rhapsody based on an OMG spec that supports:

  • FMEA (Failure Modes and Effects Analysis)
  • FTA (Fault Tree Analysis)
  • GSN (Goal Structuring Notation)
  • ISO26262
It's hot off the press, and I've not had chance to look in detail myself, but things Andy does are usually good, so it may be worth investigating if you're in that way inclined:

Friday 17 September 2021

IBM Engineering Rhapsody Tip #100 - An example of a general belly tickle problem

This is another one of my short, and silent, IBM Rhapsody tips and tricks videos. It actually came up in my tool training this week, as creating generalizations between the use cases and finding them in the browser, is part of one of my labs. The problem is sort of a user error, in that new users often press Delete on a diagram, and forget that a relation still exists in the model. When you do this because you've drawn an OO generalization relation the wrong way around, and then attempt to draw the generalization in the correct direction, then you get an error message from Rhapsody saying that you can't add a relation as it will create a cyclical relation in the inheritance structure. To fix the issue you can complete relations to populate the relation on the diagram and then properly delete it from the model, before redrawing.

Here's the transcript:

This is one of my "quickie" quick tips for IBM Rhapsody. The issue came up in my tool training delivery again this week, hence I've turned it into my video tip #100!

It's silent so you have to reeead tttthhhhe teeeext!

This "user error" basically relates to Rhapsody cleverly detecting that you're trying to add a cyclical generalization relation.

To demonstrate, I'll first add a couple of use cases and a generalization relation between them.

What I want to say is that "Give a belly tickle" is a specialization of a more general "Give a tickle" use case. 

Oops, I've drawn it the wrong way around! I'll press Delete so that I can draw it again.

Rhapsody stops me from doing this as it detects that this would create a cycle in the inheritance structure (which is illegal and would cause nasty issues).

Well, we all know why, of course? 

On a diagram, pressing Delete removes from view, it doesn't delete from model (so the relation still exists).

Tip: If we want to know if there are relations in the model not populated on a diagram then you can use the Layout > Complete Relations menu.

This will populate relations that exist but not shown. It's a good way to check for unexpected relations.

To really delete then we should choose Delete from Model from the right-click menu and we can then draw the relationship the correct way around, i.e., Give belly tickle "is a" Give a tickle use case ;-)

Tip #2: If you hold down Ctrl key and press Delete on the diagram, then it will Delete from model. When you Delete from model then you get a confirmation dialog. This is good way of knowing that you really are deleting.

Thursday 5 August 2021

Aggregated feedback from most recent Rhapsody training

The following is the feedback from my last IBM Engineering Rhapsody training using V12 of my material (mainly to software engineers + some systems/research), where 5 = Strongly agree, 4 = Agree, 3 = Neutral, 2 = Disagree, and 1 = Strongly disagree.

What did you like most about the training/other feedback?

  • Drilling the concepts through "labs"
  • Technically involving course. Fraser is very knowledgeable on the topics and is happy/ready to answer and help with any questions.
  • Really good & detailed resources, instructor very knowledgeable, easy to follow exercises
  • Practical labs and engagement were good.
  • Lab work
  • Hands on experimenting on Skytap virtual machine very useful. Having a cleanly setup environment with all the notes and lessons ready is great.
  • Doing the labs
  • Thank you.  As a last minute addition to the course, with no prior knowledge or expectation, it was clear and all very interesting.
  • It was a great course

Aligning IBM Engineering Rhapsody client with your Jazz server for Rhapsody Model Manager usage

Generally, it's important to align your IBM Engineering Rhapsody client with your Jazz server for Rhapsody Model Manager usage. This is a useful link to an IBM page that says which Rhapsody version aligns with which Jazz product:

Rhapsody and Rhapsody Model Manager integration (

Tuesday 20 July 2021

IBM Engineering Rhapsody Tip #99 - Making life easier with some proxy port automation

In this short silent video, I wanted to showcase a couple of helpers I wrote for a client. Basically, if you expect people to follow steps that are repeatable, then why not get the computer to do it? (Steve Jobs: I'd rather than a lazy engineer than a good one). I want my Rhapsody modeling to be like my iPhone, in that it just does stuff I expect without me having to think about it. In this video I show a couple of helpers that I did to speed up modeling for a client who wanted to use Proxy Ports. Essentially, I just roll the things that I would do manually into a profile plugin, and Bob's your uncle. The interesting thing about automation is that the more you do, the more ideas to speed things up pop out. Also, the market for SysML has matured a bit hence there are a few more new users, with less training and patience. I want to make it as easy as pie to model, so that they stick to the fun and creative stuff, and are able to demonstrate business value first time, rather than flop around like busy bee's unable to find a flower. 

Here's the transcript for those that need it:

In this silent video I thought I'd share a snippet of some automation I've been writing to make it easier for a client to model with Proxy Ports in Rhapsody.

The first bit here, is to speed up creation. Since, I know modeler is expected to use proxy ports, I detect the add new for part->part connector, and create proxy ports automatically. My plugin also creates the interface block that will define the contract. The 'opposite port' has the fiddly stuff done, e.g., the conjugated flag is set.

Now we can define what is exchanged via the InterfaceBlock. This is usually done by creating an interaction model, i.e., using sequence diagrams. This is an event (asynchronous signal) from the Operator to the system. I'm using a condition mark here to imply the state of the Block, i.e. I'm inferring states for the subsystems and, importantly, the signals sent between the subsystems via the proxy ports.

In "Analysis" mode, operations/events in sequence diagrams are not created automatically in the browser, meaning that it's easy to change event names. This is standard behavior in Rhapsody. There is a separate "Realization" step that you perform once the sequence is finalized. The final piece of "speed up" automation I wanted to show, is a helper that no-only realizes the events/operations, but also updates the ports and interfaces.

This is similar to a really useful helper provided by the Harmony/SE toolkit, but I've added a user interface. Still some work to do but the aim is to always explain what you're going to do, before doing it, as this helps with training people in what is going to happen.

As well as realizing the operations and adding events and event receptions to the Blocks, it has updated the Interface Block. As the rest of this video shows, I can go on to create statecharts and build an animating model of them.

Ultimately, with "speed up" helpers like the ones I've shown, we can accelerate your modeling process and engineers can focus on the creative and fun stuff.

In lieu of TrustPilot, some recent training feedback

I don't really have the volume of deliveries or business to live in the world of trust pilot. However, I do appreciate that it's good to have real feedback from real people.

As such, I thought I'd share some feedback from recent 3 day Rhapsody trainings in the last 2 months. In the following survey, 5 = strongly agree and 1 = strongly disagree.

What did you like most about the training?

  • The labs really helped enforce the theory and brought the material full circle.
  • It's a new tool for me that can capture big picture ideas and decompose to manageable chunks.
  • Labs are great. Good examples.
  • Instructor & the labs
  • Flexibility to demonstrate tasks on demand, make it easy in this environment.
  • Lots of tips and short cuts for action users 
  • I had no prior knowledge regarding Rhapsody however leaving the training I feel like I'm able to perform task via Rhapsody. The trainer was also very knowledgeable and kept the participants engaged. 
This week, I'm moving on to Version 12 of my material. I've added a simplified DOORS NG with Rhapsody half-day workshop which can be optionally used to finish things off with a fun "from scratch" example. I've also added even more differentiation to the labs to give me more options based on whether participants are experts who use Rhapsody a lot, or new to SysML/Rhapsody, so that I don't scare people with too much information, if I can help it.

Saturday 3 July 2021

IBM Engineering Rhapsody Tip #98 - Debugging user Java plugins running in Rhapsody

When you write a lot of add-ons for IBM Rhapsody, it becomes very helpful to be able to debug them. This can be a little more difficult when they're running inside the Rhapsody processes, rather than as an external Java application. There are lots of reasons for running in process though, not least because they run an order of magnitude faster, and you can tie them to a profile that adds things like menu commands and properties to control it. In this video I show how it's possible to debug them as remote java applications enabling you to set breakpoints and step through the code in Eclipse, even though the code is running in Rhapsody. You first need to add some changes to your Rhapsody ini file though. The video illustrates. Hopefully, it helps someone out there. p.s. This is a real life example.

Here's the transcript for those that need it:

This video demonstrates how it's possible to debug user-written Java plugins running in the Rhapsody process using Eclipse. 

Java add-ons for Rhapsody can be written to run as applications outside of Rhapsody, or as plugins running in the Rhapsody process (as here). Plugins can be loaded by a profile. 

A certain amount of debugging can be done using instrumentation. It doesn't always work though. In this case, I'm expecting my plugin listener to detect the event and automatically move it into an 'interfaces' package.

To determine what is happening, I want to use the Eclipse debugger to set breakpoints and step through the plugin as it runs inside of Rhapsody.

It's possible to do this by first adding some JVM settings to the rhapsody.ini file. As Rhapsody reads/writes the .ini file, always create a backup and make sure Rhapsody is closed before editing.

The JVM section is where the Java Virtual Machine that Rhapsody will use is specified.

I've added the Debug1, Debug2 and Debug3 options to my .ini file before, hence I just need to include them in Options list for the JVM.


Now when I run Rhapsody and an attempt is made to load a plugin into the Rhapsody JVM, it will wait for a remote debug connection.

To get the Eclipse debugger to connect we need to run a Remote Java Application configuration and change the port number for the Remote Java Application to 6743.

Voilà, the debugger connects with the waiting plugin running in the Rhapsody JVM.

It's now possible to run the application as normal, but set breakpoints in the plugin code. E.g., I'll set a breakpoint in the Java plugin.

That's strange...

To reload the plugin code, I need to exit Rhapsody not just close the project.

Doh!! (an unnecessary space, but I can fix it)

Hope that helps. Interested in MBSE/UML or Rhapsody training or customizations then email me.

Friday 16 April 2021

IBM Engineering Rhapsody Tip #97 - I can't get no Satisfactions (creating a browser view)

I'm keeping towards the magic 100! This IBM Rational/Engineering Rhapsody tips and tricks video shows the simple steps how to create a new browser filter that shows whether requirements have certain coverage in a model. I show that it works with both requirements in the model and remote requirements in IBM Engineering DOORS Next Jazz application. It's silent though hence if you fancy strutting your stuff then feel free.

The following is the transcript for those that need it:

The theme for this Rhapsody tips and tricks video is the Stones' "I can't get no Satisfaction". It's silent though, hence you have to sing it yourself. 

Rhapsody has a bunch of standard browser filters, e.g., filter browser to Requirements View. But look, there are some non-standard views listed here! E.g., which requirements are covered, and which requirements can't get no satisfaction?

If we add a Satisfaction to the model and save, then the requirements are removed to show they're now covered. Adding such views can speed up requirement tracing.

These custom views were added by one of my profiles. 

Let's have a go at creating the "no satisfaction" one from scratch ;-) First off, I'll do it in a profile, a special type of UML package for customizations. 

I'll create a Query element. Queries are like persisted model searches. We can define a search criteria, such as Element type = Requirement. If we double-click a Query then it runs a search in the model.

We can build a compound filter, e.g. Reference. Find elements that have exactly zero incoming relations of type Satisfaction. The compound filter is now looking for requirements that don't have satisfaction relations. Double-click enables us to test it.

What's more, the Model::Query::ShowInBrowserFilterList property is set. This means that our new Query - AintGotNoSatisfaction is listed as a browser.

Worth noting that these queries also work with remote requirements. These requirements are in IBM Engineering DOORS Next. With DOORS Next requirements, adding a standard dependency allows us to create an OSLC Satisfaction and the requirements has been removed from the filtered view of unsatisfied requirements, i.e., I can't get no satisfaction! ;-)

Interested in MBSE/UML or Rhapsody training/customizations? Email me.

Thursday 1 April 2021

IBM Engineering Rhapsody Tip #96 - The Good, The Bad and The Ugly of Label Mode

This video is a bit of a Rational Rhapsody aficionado's topic. The joy's of Rhapsody's Label Mode. Most effective use of this has been when presenting quite a complicated diagram, like an executable state machine or sequence diagram, to lay audience. I'm sure there are some other great examples of usage out there also ("The Good"). I do highlight some of the dangers, however. When you write things not knowing that label mode is enabled, for example.  The video is silent though, so you'll have to hum Ennio Morricone's fantastic spaghetti western theme song, if you get bored with reading my captions.

Tuesday 16 March 2021

New IBM Engineering Lifecycle Management (ELM) User Group page

IBM have set a new User Group page for Engineering Lifecycle Management (aka Jazz Continuous Engineering platform). They're saying this will be the central point of all IBM ELM activities, hence you may want to check it out:

There will be features allowing IBM to communicate to the user groups and register to events.

It is open to the public. IBM encourages partners and clients to join. 

Academia is also welcome.

Tuesday 9 March 2021

IBM Engineering Rhapsody Tip #95 - Why diagram ownership is important for Internal Block Diagrams

This video covers an area where new users of SysML often struggle, i.e. understanding the differences between Blocks and Parts, and the role played by the diagram frame of an internal block diagram. Fundamentally, in SysML the frame of the ibd is normally a block and the ibd represents an assembly of parts owned by that block. Within my old friend Rhapsody, unlike Cameo, there's not a context selection method on a diagram that defines the context of its frame. The context of the diagram is determined rather by the ownership of the diagram. This means that diagram ownership is critical. This is why I normally recommend that new users are careful to create internal block diagrams as children of blocks rather than at package level. Related to this is that if you drag an element on to an internal block diagram and it is out of context, then it will be displayed with a dashed line, something new users often struggle to understand. This is because it's not owned by the element that the frame represents. This is video #95 of my Rhapsody tips and tricks video channel that I started 6 years ago.

Here's the transcript:

Hi, in this short video I'm going to show why it's important to have Internal Block Diagrams owned by Blocks rather than being children of packages.

So, I'll start by creating a quick SysML project and I'll create a classic Block Definition Diagram with a structure. I'll create a System A which has a Subsystem B and Subsystem A. The way I create a structure is with Directed Compositions. I'll create a part A and a part B. 

By default, Rhapsody will name the part with the word "its" followed by the name of the Block but I can name it what I like. 

So what we have here is essentially an internal structure with parts. The block definition diagram defines the relationship between blocks but blocks are types of things and parts are named usages of those types, usually within the context of another block.

... although Rhapsody does allow you to also have parts which are global, i.e. owned by a package.

If I create an internal block diagram where I want to show these parts, then normally the frame of that diagram would represent the element, i.e. Block, that owns those parts. So, if I create an internal block diagram at package level, then we can see in the frame that this is a package diagram of a package called default.

I can put the parts in it and you can see that the dotted notation will tell me where in its nested structure it is.

Of course, I could put the part into the System A block here and that removes the dotted notation.

But the frame here, doesn't represent system A. It doesn't represent anything that's a classifier. Let me just add a port on the boundary of System A here, and another port with a connector.

Now, if I create an internal block diagram underneath the System A block then the frame tells us that this is an internal block diagram of a block called system A.

That means that the frame represents the block System A. This means that you can show a port of System A on the frame, and the things inside that frame then would normally represent parts that are owned by System A.

So the Block Definition Diagram is a diagram that shows relationships between Blocks and blocks are types of things.

The internal block diagram is a diagram that shows me the relationships between parts which are usages and the frame represents the block that owns these parts.

Let's see what happens if I have a nested hierarchy that goes deeper. Maybe component C is a child part typed by  Subsystem A and component D has a child part typed by subsystem B.

If I put part D here on the internal block diagram, then you can see that it's dashed because part D is not directly owned by subsystem A, rather part D is owned by subsystem B.

If I move it into the correct context then it's boundary is no longer dashed.

So, if I drag something on to an internal block diagram, for example a Block, then it's dashed because it's not owned by the element that the frame of the ibd is representing.

Internal block diagrams are diagrams of the internal structure of a block, so things that are not in that internal structure are going to have dashed lines on them.

There's two fundamental things here really. One is that blocks are types of things and that parts are named usages of blocks, usually within the context of another block. 

Secondly, an internal block diagram is a diagram of those usages and how they're connected within the context of a a block, and that the frame of the ibd normally represents that owning block.

In Rhapsody, there's no context setting on the internal block diagram. The internal block diagram frame is determined by the ownership of the diagram. So the internal block diagram here is owned by system A which means that its frame will represent system A. This is why I always create an internal block diagram underneath a block, rather than at package level (unless you have parts which are global - which I tend to avoid anyway).

I hope that helps. Don't forget that I have a business that can deliver customised training in Rhapsody that suits your needs and your budget, so feel free to email me if you want more information on ways of accelerating your adoption of successful model-based systems engineering with Rhapsody.

Monday 22 February 2021

IBM Engineering Rhapsody Tip #94 - Downloading and installing Rhapsody 9.0.1 (Intermediate)

In my previous video, I covered adding Cygwin/gcc compiler to an existing Rhapsody installation. This video is actually the precursor to that, and covers installing the latest Rhapsody 9.0.1 (to date) without a compiler. The actual steps you may choose to use for your installation may different. However, I point out a couple of important things. Firstly, how the TELELOGIC_LICENSE_FILE environment variable is used by Rhapsody to find either a license server or a FlexLM license file, and secondly how the rhapsody.ini file is used by Rhapsody to determine default edition. I also create a simple test project that can be used to verify whether your compiler is installed correctly (actually the steps for doing this are in the previous video #93).

SysML v2 2021-01 Incremental Release

For those who may be interested:

Incremental release 2021-01 of SysML v2 is now available at

This release includes language support for filtering of elements imported into a package (“smart packages”), enhanced support in the Tom Sawyer visualization tool to allow mixed views on a diagram, and a prototype implementation of pagination of return data for one API endpoint.

Complete release notes can be found at the links below.

SysML v2 Pilot Implementation:

SysML v2 API and Services:

Updated drafts of the specification documents and training material can be found at

Thursday 11 February 2021

IBM Engineering Rhapsody Tip #93 - Adding Cygwin/gcc compiler to simulate systems (Advanced)

Always interested in new ideas. This ones actually at the suggestion of Bruce Powell Douglass. One of the questions he gets asked a lot...

You may have installed and used Rhapsody for UML/SysML for a while just drawing diagrams, only to discover later on that there are more advanced executable MBSE methods such as Harmony/SE and my ROCKETS-based modification of it (one of my passions). This narrated video covers what you need to do to your installation in order to extend it to simulate systems or compile C++ code down the line. 

At this point you will discover that you need to install a C++ compiler but, as the video highlights, it's possible to install this compiler after Rhapsody, without having to reinstall Rhapsody. In this video, I demonstrate by going through all the steps to install the minimal parts of the open source Cygwin/gcc compiler for system simulation purposes. I also show steps for verifying the gcc compiler is working, recompiling the framework (and what this means), and testing it with a model. Hope it helps.

SysML v2 Demonstration session from the INCOSE Internal Workshop

For those that way inclined, INCOSE UK put out an interesting link to a SysML V2 video last week. I thought I'd publish it here. This is a recording of the SysML v2 Demonstration session held on 1 February 2021 at the INCOSE International Workshop available for streaming here. The video can also be downloaded from this page. This is a 2-hour session including a demo of the SysML v2 language pilot implementation by Ed Seidewitz and a demo of the SysML v2 API and services pilot implementation by Manas Bajaj.

Thursday 28 January 2021

IBM Engineering Rhapsody Tip #92 - Creating a simulation with panel diagram (Intermediate)

Been a bit busy recently but getting close to the magic 100th video! I save stuff for my training courses but this video's an ad-libbed demo in response to the question "how easy is it to create a simulation with panel diagram in Rhapsody?". It will work in pretty much any version of Rhapsody, as long as you have installed properly with a C++ compiler (I have separate guidance on this) and the necessary licenses. Certainly, making use of statecharts in a simulation is a lot easier than activity diagrams because it is a much smaller syntax. You do need to know more when it comes to the art of drawing state machines and techniques for expressing certain types of behavior, or getting multiple state machines to interact and interface (making choices about port types and interfaces). In summary, once you know what you're doing, then it's relatively easy. This is something that can come from a combination of experience and training. Hope it's of interest:

Monday 25 January 2021

Reflections on 3 aspects of MBSE training

There are 3 aspects to MBSE training:

1. Training in how to use and configure the tool.

2. Training in understanding the modeling language (e.g. different diagrams in SysML/UML and their syntax).

3. Training in how to apply a method or process.

Obviously, type 3, above, depends on which process/method you are applying. However, it's hard to learn a process for a tool and language, if you don't understand the tool and the language.

Of course, if you do have a chosen method that applies to a team then you could do "role-based" training, i.e. teaching people just the bits needed for their role. What people often forget is that the role of the process/method is to enable teams to scale, e.g., getting people to be able to work in parallel on the same project. As you scale, you might use different types of enablement techniques, e.g., videos/tutorials. This is aided once you know your method as it can be targeted at segments that individuals need to know, rather than giving them a book on UML/SysML (which tends to lead to "mushrooms" of people pulling in different directions).