Friday, 23 October 2020

IBM Engineering Rhapsody Tip #86 - The Parts Browser - a SysML profile feature (Intermediate)

I wanted to show how it's possible to create a custom requirement traceability browser in Rhapsody. First off, though, it's worth understanding the Parts Browser in Rhapsody; a feature added by Rhapsody's factory SysML profile. The parts browser allows you to launch a browser to drill down a Block/part hierarchy tree. The parts browser is available as a submenu on the right-click 'Browse Hierarchy' menu  The browser is formed using a context pattern which defines how to traverse relationships in the model to form the browser. In this short, caption-based (i.e. silent) video, I show how it works and then look at some of the properties behind it. In the next video in this series, I'll show how it's possible to use a similar technique to create a browser for showing requirements traceability.


Here's the transcript for those that need it:

This silent video shows the Parts Browser: a SysML profile-based example of Rhapsody's 'Browse Hierarchy' feature.

The Parts Browser is added by the SysML profile, so let's create a SysML project.


The right-click menu now has a Browse Hierarchy > Browse Parts submenu (added by the SysML profile) which launches a Browse Parts window.


Let's create some blocks and parts using a SysML Block Definition Diagram (BDD). Use of Directed Composition relationships on the BDD will define the parts.


In the normal browser the tree stops at parts and we have to right-click to navigate to their types. The parts browser, however, allows us to drill down recursively, e.g. the itsBlock_4 part is typed by block_4.


The tree is dynamic. We can drill down the complete block/part hierarchy.

So, how’s it done?

Well, like many things in Rhapsody, it's done using properties, in this case conveyed by the SysML profile. These 3 properties define the Browse Parts submenu name and pattern (for a Project).


The metaclass for a Block defines its submenu name and context pattern. This context pattern includes displaying attributes/operations contracted on the ports.


Let's create a port with an interface to illustrate.


Now, if we right-click a Block then the context pattern we saw earlier will come into play.


We can create our own custom browsers, if we wish. In the next video in this series, I'll show how to create a requirements traceability browser! ;-)

Thursday, 15 October 2020

Smartfacts: Model repository and web publishing for multiple tools not just Rhapsody

Interested in a model repository and sharing platform for many different types of modeling tools, not just Rhapsody? Check out the MID smartfacts technology:


Background: IBM Rational brand originally worked on the Design Manager repository-based technology, an ontological database with a Jazz-based client for web-based access. Originally they moved it to support their Java-modeling Rational Software Architect (RSA) tool. They then acquired Telelogic and began adapting it for Rhapsody, ultimately shipping a Rhapsody Design Manager (RDM) variant. At the same time a web-publishing adapter was also available for MathWorks Simulink models and was covered under the RDM licensing. With the move away from repository-based to the file-based Rhapsody Model-Manager technology (RMM), the Simulink aspect (and ability to write adapters to other tools) got dropped, potentially leaving a gap for companies interested in a library and linking capability for a range of tools. Could smartfacts plug this gap? 

 

Wednesday, 14 October 2020

An evening or self-paced class for contractors/people looking to upskill?

I'm exploring the idea of running an evening/weekly call-type class or self-paced class for contractors/people looking to upskill with SysML/Rhapsody/MBSE knowledge. It's not entirely clear how much interest there would be in this, so I will do a trial if I can get enough interest. If you are interested let me know. I've updated the form here to give it as an option. 

A bit of background: Historically my training focus has been business-to-business, e.g. running private Rhapsody training for companies adopting the tools on either a one-off or a series basis. I did have a lot of success with open training run in conjunction with HORIBA MIRA but Covid-19 and other reasons have put a hold on face-to-face training. It can also be hard for individuals (contractors and engineers looking for personal development) to access such training as it requires a lot of commitment of time. I'm therefore thinking of some lighter-weight, more lower cost options that I could deliver now while lots of people are working from home, and across a broad geography (particularly outside the UK). 

Friday, 9 October 2020

IBM Engineering Rhapsody Tip #85 - Using change events with SysML proxy ports (Advanced)

Ok, I'm back into more regular update videos. This again, is a slightly more advanced topic, although it also explains a little about what SysML proxy ports and Interface Blocks are and one of the ways they differ from standard UML ports and interfaces. This IBM Engineering tips and tricks video follows on from video #85 and shows how to get flow properties and change events to simulate with SysML proxy ports. The key thing is that in addition to using the change event and the auto-generated setter, you need to set both ports as behaviour ports. This is actually picked up by the Rhapsody model checker as a warning, as this short (and caption-driven, i.e. silent) video illustrates.


Here's some transcript (for those who want the gist):

Change events were originally developed to work with SysML flow ports. However they also work with SysML newer proxy ports. This video explains how to get them working for both.

In summary, change events are based on a ch followed by the name of attribute (with first letter capitalised). They require that the publisher of the change uses the setter. So, how do we get them to work for proxy ports?

Well, I proxy port is the newer type of port for SysML, and they work with Interface Blocks. Interface Blocks like UML Interfaces are designed to aggregate or group elements in a desired contract, i.e. they are not designed for single elements.
  
To flow data in an InterfaceBlock we would introduce an owned element called a flow property. Flow properties have a direction tag associated with them. This needs to be explicitly set to the direction the flow is occurring.

Proxy Ports can then be added which specify the use of the interface block.
 
 As the interface block is carrying flow properties, Rhapsody is showing direction inferred by their direction tags. The corresponding receiving proxy port is typed by the same interface block but is set to conjugated.

This is notated on the diagram by presence of the tilde symbol (~).
 
The ports can then be connected. This is almost ready to work. However, if I run now then you’ll see that the flow and change event are not occurring. A clue for the reason is actually picked up by the Check Model as a Warning.
 
If we want change events and flows to work for proxy Ports then we need to check the behavior attribute on the General tab for the port. If we only do this for the subscribing port then the simulation will still now work. This needs to be done not just for the subscribing port (with the reception for the change event) but also the publishing port.

Thursday, 1 October 2020

Reflections from last weeks training

Training from last week was interesting. I realized just how much there is to take in when adopting model-based systems engineering for the first time. Enthusiastic people definitely help, not just engineers but also management giving them their support. It's not just knowing the ins and outs of the tools (both the modeling tool and how it integrates with others) either, there are so many aspects to the language and many ways to use it. It was good that we finished with workshop that looked at an example process though. I think when you see an end to end example built around your problem then it helps people appreciate how an appropriately selected process can significantly improve requirements definition and systems architectural work.



IBM Engineering Rhapsody Tip #84 - Getting statecharts to react to change events (Advanced)

This short and silent caption-based tips and tricks video came from a subscriber emailing me for help on getting change events to execute correctly with SysML proxy ports. In this first of two videos, I thought I'd recap some of the fundamentals about how change events in Rhapsody statecharts work, and what they're for. The key tips in this video are really that you need to make sure that you use the setter operation when changing the value of attributes / value properties. Setters and getters (what are often called a mutators and accessors in C++) are auto-generated. The setter will follow the convention of the word set followed by the name of the attribute capitalized. Change events are used as triggers in Rhapsody statecharts for reacting to a change of data. They also follow a naming convention which is the characters 'ch' (for change) followed by the name of property (capitalized). Hopefully the video explains for those who're interested! 


Here's some of the transcript, in case it helps:

Change events were originally developed to work with SysML flow ports. However they also work with SysML newer proxy ports. This video explains how to get them working for both.

In this project I have two parts both with a ‘batteryLevel’ property. In the IBD they’re connected via similarly named SysML flow ports; the port type introduced in the original SysML spec to handle data and material flow.
 
If I run the simulation then you’ll notice that the batteryLevel is not forwarded. This is because the setter is not being used in the sending blocks statemachine. Let’s correct that.
 
For those geeks amongst you, it’s actually the code in the autogenerated setter that causes the flow to occur. If you don’t use the setter whenever the value changes, then you don’t get a flow.
 
We’re now getting the flow. However, partC is not currently reacting to it. This is where a change event comes in. A change event in Rhapsody begins with a ch prefix.
 
You can now see the battery level change event occurring
 
In summary, change events are based on a ch followed by the name of attribute (with first letter capitalised). They require that the publisher of the change uses the setter. 

So, how do we get them to work for proxy ports? Well, that's the next video.

SchemaSys video link - Visualizing an electrical circuit diagram built using SysML

Here's an interesting link for people who might be interested in thinking outside the box (so to speak ;-). It seems that John Brush has ideas for visualizing SysML diagrams in more interesting and domain-specific ways, e.g., as electrical circuit diagrams!

Something to discuss at an INCOSE MBSE  working group meeting, perhaps ;-)