Thursday, 22 August 2024

IBM Engineering Rhapsody Tip #110 - The Function Block Method

This video shows how it's possible to build a very powerful description of a systems structure and behavior using only two SysML diagram types, if you embrace the notation of function blocks and using BDDs and IBDs to do both. To get this to really work, I've had to extend Rhapsody with my open-source profile called ExecutableMBSEProfile. 


The video creates a project from scratch including bdd/ibds for both behaviour and structure and then shows some of the notation that's possible dove-tailing them together. The ability to show functions inside structural elements together with signals is something similar to Capella/Arcadia. Personally I find it interesting that you don't need something complex to describe something complex. Somehow by limiting the notation you can achieve more, especially as it means that you only really need to understand two SysML diagram types to read the diagrams.

This is the transcript in case that helps:

00:00:00

In this video I'm going to show you the executable MBSE profile again, and then I'm going to do something a bit different with this, which is to explain one of the workflows you can do with this profile without using activity diagram, sequence diagrams or state charts and instead doing an entire project with just two diagrams.

The intent of that methodology is to simplify SysML so, if you understand how to do block definition diagrams and internal block diagrams for structure, then you would understand how to do it for behavior and then you can take those two compositional trees and dovetail them together. This is an approach around function block modeling. I'll do the insulin pump system again.

00:00:48

And I'm going to use the executable MBSE profile. This is the four three E version. If you look on my executable mbse website here (www.executablembse.com), then you can see that there is a link to be able to get this profile from GitHub.

00:01:13

Now, conventionally you might start a project with use cases and use cases you might decompose with, say, an activity model. An alternative to that is to start with blocks and do a decomposition using a block model, so the first thing I'm going to say is let's define a system architecture structure.

00:01:32

Using a block definition diagram and this is for an insulin pump system.

00:01:45

And the insulin pump system has an insulin pump, a continuous glucose sensor, and a blood glucose meter.

00:02:09

This is something called a block definition diagram in SysML, and it's derived from the class diagram in UML and allows me to do directed decomposition to be able to create part property relationships between elements.

00:02:31

The insulin pump system now has three part properties typed by these subsystems.

00:02:40

Well, if I did the same within the behaviour domain then I could do it with something very similar and this profile adds the concept of a feature which might be to deliver basal insulin.

00:03:02

This, rather than being a structural block, is a functional block. I'm able to say well to deliver basal insulin, I need to measure glucose level, calculate basal adjustment and deliver insulin.

00:03:29

Obviously, there might be more detail than the real world, but this is just an example.

00:03:40

I use decomposition to show that there's a functional decomposition and the only real difference here between the feature block and function block is I'm saying the feature block is at system boundary level and I do have some relationships that I can do between the system block and the feature block to say that a feature is a system, for example, using generalization, that I don't allow with these function blocks.

00:04:06

But I do allow function blocks to be decomposed to any arbitrary level as do I allow within the structural model subsystems to be decomposed into any any level but not systems. So we're making a language choice within the profile to put meaning around these different types of block, but fundamentally it's a block definition diagram and the notation is the same across both.

00:04:30

So you would say conventional systems projects such as Magic Grid with Cameo or Harmony/SE with Rhapsody would start with use cases and I could could do that but I'll show you an alternative which is that I've added the idea of a context diagram.

00:04:51

Where the context diagram is going to show me the relationships that the system has with external actors.

00:04:59

So it's very similar to a use case diagram. This is an internal block diagram. It's got parts which are typed by actors.

00:05:07

Obviously I haven't really got drivers using an insulin pump system, I've probably got a patient so if I rename that actor as a patient, I could say that there's an interaction between the patient and the system. The patient might request a bonus correction and the system delivers insulin.

00:05:44

This simplified internal block diagram does have very simplified palette and we're using flows between part properties, and the flow is carrying signals or what Rhapsody calls events, because that's one of one of the easiest things to hook other things into. Lots of different diagrams within SysML are able to capture exchange items using Events/Signals. I could show within this insulin pump system using

00:06:16

A feature usage which is typed by that (Feature).

00:06:22

And establish the flows to those features. If you think of this as similar to what a use case would do, the difference is instead of having an ellipse here and having a use case, I've got a block.

00:06:36

To do this (project), I've only actually used two different types of SysML diagram so far. I've used block definition diagrams to do decomposition. I've used a high level internal block diagram. When I say high level, I mean an internal block diagram where the part properties are global. I've got the concept of a block called a feature which decomposable into functions.

00:06:57

And I can then establish relationships between these blocks, and although I could do it with allocation dependencies, what this opens up quite easily is the ability to do allocation through composition. I could say, that my.

00:07:16

Calculation of basal adjustment is done by the insulin pump.

00:07:25

My deliver of insulin is actually also done by the insulin pump.

00:07:34

My measuring glucose levels is done by the continuous glucose sensor.

00:07:42

If I wanted to, I could go into using internal block diagrams.

00:07:48

I've got an internal block diagram here. I can populate the parts.

00:07:53

And I've got a helper here to to be able to do that. Some of these are function usages. Some of them are subsystem usages. If I just say, populate them all.

00:08:05

You'll see how it it dovetails the two together.

00:08:10

Just can pack this a bit than because my screen size is not so good.

00:08:14

The insulin pump then might might have connections with the continuous glucose sensor.

00:08:26

The helper is going to automatically create some interface blocks and conjugate one of the ports. If I do that, I could say that the measurement of the glucose level.

00:08:37

So might might bits or less.

00:08:41

This way, that's the way of doing it.

00:08:45

I could say measuring glucose level produces flows on this connector into these parts, so you see how I'm using part properties with a structured compartment here to be able to see both entities.

00:09:11

So that will be our flow input into that function you can see it's part of the insulin pump.

00:09:22

This gives me some sort of unique but recognizable views, which I can't quite do as clearly/closely using activities as I can with parts and blocks.

00:09:38

And this might be a pre step. I could take that feature.

00:09:44

And then take the part properties and chain them purely in a functional model.

00:09:54

So I measure glucose level.

00:09:58

And that flows.

00:10:02

I haven't typed these by events, but I could that flows to calculating the basal adjustment and then calculating the basal adjustment flows into the delivery of insulin.

00:10:14

And the helper here is creating some flow ports there, and if I wanted to I could put some conditional logic or parallel logic and I'm using business process (BPMN-inspired) notation here because that works quite well in nodes, but this is actually an internal block diagram being used to perform the function that an activity diagram would have.

00:10:39

So it's relatively powerful notation but I've got the whole port/part capability in that this measure glucose level function block here, assuming that essentially the capability and it owns things like a requirement diagram.

00:10:57

And show requirements that the function block owns. Then if I allocate this function block to a subsystem, then I'm essentially allocating the requirements.

00:11:08

And these function blocks then become these reusable elements. So I could create a completely different architecture with different subsystems and allocate the same functions if I wanted to. Or I could start to use some of the things of object orientation such as generalization and composition to assemble reusable functionality as a block, and then use that functionality in another system. It's SysML but all these diagrams are done entirely with the notation of block definition diagrams and internal block diagrams. I haven't used any use cases. I haven't used any activity diagrams, haven't used any sequence diagrams.

00:11:49

But I can achieve quite a lot with a very small syntax.

00:11:53

And once you understand that small syntax, you can express quite interesting relationships and start to assemble systems from reusable components. So it's a more fluid, dynamic way of modeling a system.

00:12:08

Which does rely on some extensions here to be able to specialize the types of blocks, but is something that may be interesting if you're into this idea of functionally decomposing system capabilities rather than trying to say, that we need to express our system in terms of a SysML sequence diagram or state chart.

00:12:26

So I thought I'd show you that it's a slightly different approach to SysML. There's lots of different ways you can use SysML, but I think the idea of only using two diagrams is actually quite clever (i.e. powerful) if you need any more information then let me know.



No comments:

Post a Comment

Note: only a member of this blog may post a comment.